|
From: Tom H. <th...@cy...> - 2003-10-22 13:12:46
|
In message <1066783120.4409.10.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2003-10-21 at 16:08, Tom Hughes wrote:
>
>> Specifically the wait4 system call exists with ERESTARTSYS but is isn't
>> restarted and the waitpid library call returns 114 which is the number of
>> the wait4 system call, as shown here:
>
> Gak. I tested all this, honest. Try this (manually hacked up, so the
> lines will be all off) patch.
That seems to fix my test case, yes.
Naturally enough that meant that it didn't fix my original problem in
our software though ;-)
Several hours chasing around and poring over linux kernel source have
led me to a sort of understanding about my actual problem and a way to
work around it in valgrind.
My original thesis that the SIGKILL wasn't making it to the child is
in fact correct, as can be seen by the fact that when the parent hangs
waiting for the child the child is still running quite happily.
What seems to happen is that there is some sort of race condition such
that if the SIGKILL is sent by the parent after the child process has
called exec() but before the new executable actually starts running
then the signal can disappear. This only seems to happen if the
process that calls exec() has more than one thread, as is the case now
that valgrind has a proxy thread running.
My money is on the culprit being de_thread() in fs/exec.c in the
kernel, which does all sorts of mucking about to kill the extra
threads and unshare the signal handling apparatus. Either the signal
is pending and is discarded when a new clean signal handling structure
is created for the thread doing the exec() or the signal is being
delivered but is only killing the other threads and not the one doing
the exec().
Either way, patching valgrind to explicitly kill the proxy thread in
the pre handler for execve seems to work around the problem... Whether
this is a safe thing to do isn't totally clear to me though.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|