From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: spawn problems (windows 98?) 4 Aug 1998 12:31:13 -0700 Message-ID: <19980804151913.B25156.cygnus.cygwin32.developers@cygnus.com> References: <3 DOT 0 DOT 5 DOT 32 DOT 19980804165143 DOT 007de820 AT mail DOT mel DOT cybec DOT com DOT au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Trevor Yann , cygwin32-developers AT cygnus DOT com 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