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

Reply via email to