Mail Archives: cygwin-developers/1998/08/04/12:31:13
On Tue, Aug 04, 1998 at 04:51:43PM +1000, Trevor Yann wrote:
>After some more detective work, I managed to get a stack trace at the time
>of the hang.
>
>The stack looks like this:
>(tos) block_sig_dispatch
> proc_subproc
> wait4
> waitpid
> waitchld (function in bash)
> sigchld_handler (function in bash)
> call_handler
> ?
> ?
> CreateProcessA
> spawn_guts
> spawnve
> spawnv
> execute_simple_command (bash function)
Are you sure about this stack? If CreateProcess is getting interrupted
by a signal then I think that's in violation of the documentation for
SuspendThread.
This does look like a deadlock condition for the sig_dispatch mutex, though.
>What has happened is a child process has died whilst CreateProcess is
>creating a new process. Bash handles SIGCHLD by (eventually) calling waitpid.
>
>Normally this won't happen, because bash blocks usually signals before
>calling fork. My modifications now block signals before calling spawnv. Net
>result is that I don't see the problem anymore.
>
>Is bash misbehaving by calling waitpid from within a signal processing
>function?
No, not at all. That's perfectly acceptable behavior.
>I guess that the sig_dispatch mutex is being grabbed somewhere before the
>processing of SIGCHLD, but I can't see where.
>
>If we are to support this sort of scenario, then we'll have to make some
>changes to protect against the problem.
It is certainly easy to protect spawn from signals and it definitiely should
be done. I'm concerned about SuspendThread being able to stop a CreateProcess
though. That doesn't bode well for other system routines. It sounds like
we'll have to be blocking a lot of these.
Could you try this with the cygwinb19.dll.gz in
ftp.cygnus.com:/private/home/cgf ? If nothing else, the strace log should
show who's locking what.
--
cgf AT cygnus DOT com "Everything has a boolean value, if you stand
http://www.cygnus.com/ far enough away from it." -- Galena Alyson Canada
- Raw text -