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
^
pid
>and you should see a SIGSEGV.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
