|
From: Eyal L. <ey...@ey...> - 2005-01-27 08:35:20
|
Jeremy Fitzhardinge wrote: > 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? Can you ask VG to tell how many is "lots" in this case? > 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? I don't think so. I can describe the scenario for the program in question. We have a few servers running, and they stay up for the full test period. A sequence of tests is running. Each test runs a few programs (maybe a dozen) in order. Each connection to a server gets a thread which normally serves it from start to finish. When no client is active there should only be some housekeeping threads on the servers. Between tests we run this 'ssashut' program, which is a very simple one. It only issues one transaction, telling a server to release cached resources. Naturally, it gets a thread on the server. All of our programs run as a thread, meaning main() is practically empty, it just launches a thread and then joins it. This way we do not need to control mains, just threads. I short, I do not expect too many threads to be active (or exiting) when ssashut is run. Is there a way to request VG to log a global status report on demand? I can then run this status report before each ssashut. I wonder is some resource is not released by VG itself. Note that some VG processes (my servers) start early and never exit before the failure, does VG delay some housekeeping to when a process exits? Just a thought. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |