Mail Archives: cygwin/2005/06/25/11:26:08
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.
cgf
--
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/
- Raw text -