On Sun, 2017-11-19 at 20:04 -0500, Brent W. Baccala wrote: > On Fri, Nov 17, 2017 at 3:14 PM, Svante Signell <svante.sign...@gmail.com> > wrote: > > Thanks a lot for your patches for rpctrace. Now more failing programs > > can be traced, where the standard version fails. There are still some > > examples hanging hard on gsync_wait or entering an infinite loop. > > > > And thank you for writing the first ever documentation of rpctrace :) > > You're welcome, on both points.
Thanks again, Ill try to learn the rpctrace syntax. > > Thanks anyway, I'll use your patches for local use. And if you want > > more examples of where rpctrace hangs or loops forever, or testing of > > new versions, please let me know. > > > Sure, let's take a look. I've spent a good bit of time studying rpctrace, so > if you've got some test cases that uncover bugs, I might be able to understand > them. Hi again, below is the terminal output when running bug347.x causing rpctrace to hang at gsync_wait, even with your patches. Unfortunately the libgo.so.12.0.0 library is needed too. I'll put these files on darnassus.sceen.net/~gnu_srs/gccgo-8 together with the rpctrace output. I'll also put the executable bug348.x together with the rpctrace for it there. For this file rpctrace finishes, child exiting with code 2. I still don't know where the problems arise. (I'm not very fluent in rpctrace) The terminal output from running bug348.x is given below too. This problems persists from gcc-6 (and earlier) to gcc-8. In case you need the shared libraries and the executables from earlier builds, please let me know. /part2/DEBs/gcc-8/gcc-8-8-20171209-1.1/build/gcc/testsuite/go/bug347.x BUG: bug347: cannot find caller Illegal instruction /part2/DEBs/gcc-8/gcc-8-8-20171209-1.1/build/gcc/testsuite/go/bug348.x BUG: bug348: cannot find caller panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=2 addr=0 pc=0] goroutine 1 [running]: panic /part2/DEBs/gcc-8/gcc-8-8-201712091.1/build/../src/libgo/go/runtime/panic.go:543 And FYI: gdb is totally unusable, the only output is threads are created an then a hard hang of gdb, only resolvable with kill -9 from another terminal. I tried to start another gdb on /hurd/ext2fs an attaching to the hanged process but did not succeed. Maybe something was not made in the right way.