From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: Please try a snapshot - final push for 1.5.19
Date: Sat, 24 Dec 2005 03:07:24 +0000
Message-Id: <122420050307.27463.43ACBB6C0002941F00006B4722073007930A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> 
> I played with this all day and I can't convince myself that it isn't a
> readline bug.  It seems like there is a situation where bash/readline
> unmasks SIGINT and potentially lets a stray CTRL-C in while the signal
> handler is still carefully dealing with signals, causing recursion and,
> eventually, an overflow of cygwin's signal stack.

Indeed it is a readline bug; Chet Ramey confirmed it:
http://article.gmane.org/gmane.comp.shells.bash.bugs/8559

However, he didn't mention whether it was fixed prior to or
after readline 5.1, which I am still in the middle of preparing
as an experimental package.  Nor did he mention directly
what the fix is, or I might have been able to prepare a
patched readline 5.0 with the fix.

> 
> In any event, this isn't a regression and, unless I have an amazing
> insight sometime soon, I don't think there is any way to fix this
> in the cygwin DLL.

Agreed - cygwin shouldn't have to go to great lengths to
work around a program that mistakenly calls kill() from inside a
signal handler.

--
Eric Blake
volunteer cygwin readline maintainer

--
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/