|
From: Jeremy F. <je...@go...> - 2005-01-27 07:16:51
|
On Thu, 2005-01-27 at 17:23 +1100, Eyal Lebedinsky wrote:
> Jeremy Fitzhardinge wrote:
> > Could you try again with --trace-signals=yes.
>
> Done. '3' is a good run, '4' is a failed run.
OK, this explains what's going on. It is the same problem as before -
it's getting a SIGSEGV to grow the stack, but it's missing siginfo so it
doesn't realize its a stack growth. Then it tries to report the
sigsegv, but dies while trying to print the backtrace.
So the question is, why are there lots of signals still being queued?
The code currently takes care to mop them up where ever the signals are
being sampled, but I guess that won't happen if the master is blocked in
a syscall... Hm.
Can you go into a bit of detail about the process/thread structure here?
Those two traces are from a single-threaded program, but for this bug to
occur (and be Valgrind's fault), there needs to be lots of thread
exiting going on. Is there a process where:
1. the main thread is blocked in a syscall, while
2. other thread(s) are creating lots of other short-lived threads?
J
|