On Mon, Mar 19, 2012 at 2:30 PM, Steffen Daode Nurpmeso <sdao...@googlemail.com> wrote: > Sorry folks for this shitty report, but i thought it's maybe > better to send it out than not to be able to sleep or so. > I guess it's somehow related to the rthread wait4() path, but of > course i dunno. Here's what's happened: ... > Note i (yet) use(d) a very primitive compilation approach > - i simply do 'make all', which sometimes requires changes by hand > (e.g. today drop of SO_JUMBO in kdump). *This* is only a fellow > traveler virtual box, and doing the full rebuild blocks normal > work out some hours longer, so.. > I had not yet time to check this on a real box.
I don't know whether it's your non-standard build procedure, a virtual machine that lies, or something else, but I'm certainly not seeing the wait4() looping problem you show when I try it on real hardware using the standard build procedure. If you can reproduce it on real hardware with the standard build procedure, then please report it here. > Puke! I had to run a debugger :-((: > > (gdb) break vfork > Breakpoint 1 at 0x401a50 ... > Breakpoint 1, 0x00000002088b0f90 in vfork () from /usr/lib/libc.so.62.0 > (gdb) step > Single stepping until exit from function vfork, > which has no line number information. Single-stepping past vfork? Has that *ever* worked? > gcc: Internal error: Trace/BPT trap (program cc1) > Please submit a full bug report. This may be a side-effect of the work that's in process for adding thread support to ptrace(), but seems odd. <shurg> > Well; unless there is interest in something i'll do a complete > cleanup and recompile tomorrow. > I would report if the problem remains, then. If it works on real hardware, then you should have a conversation with the support channel for your virtual hardware. Philip Guenther
