Bash 3.0-2 and kill

Christopher Faylor
Sat Jun 25 17:27:00 GMT 2005

On Sat, Jun 25, 2005 at 11:22:04AM -0400, Christopher Faylor wrote:
>On Sat, Jun 25, 2005 at 09:05:12AM -0600, Eric Blake wrote:
>>According to Igor Pechtchanski on 6/24/2005 10:50 PM:
>>>>Given that if cygwin was this broken all sorts of other things would be
>>>>broken as well, this is more likely a problem with bash.
>>>One reason for my guess was that I recalled discussions of bash using
>>>pretty specialized spawn techniques, and it was likely to have some
>>>corner case interaction with signal handling that normal programs
>>>wouldn't encounter.  There may also be something different about the
>>>SIGCHLD that bash is getting when the child is killed with SIGKILL.
>>>But that was no more than a guess, and yes, it's quite possible that
>>>there's a bug in the bash signal handler.
>>I wouldn't at all be surprised if it is a bash bug, since I blindly
>>forward-ported the job handling tweaks made for cygwin in 2.05b-17 to
>>3.0 without seeing what else changed upstream in 3.0.  I am still
>>trying to reproduce the crash with a debugging build to get a
>>stacktrace, and haven't succeeded at it yet, so a more exact formula
>>from the OP would indeed be useful.  Also, for those who have seen the
>>crash, please include in your report what "set -o" and "shopt" display,
>>since some of the shell options affect the job handling behavior.
>This seems reproducible:
>  c:\>gdb bash
>  (gdb) r
>  bash-3.00$ sleep 300&
>  bash-3.00$
>In another window kill the sleep's, then hit enter at the bash prompt
>and you should see a SIGSEGV.

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list