Re: readline signal bug

[Christopher Faylor]

On Fri, Dec 23, 2005 at 09:59:05PM -0500, Chet Ramey wrote:
>Eric Blake wrote:
>> This was reported on the cygwin list.  I don't know if bash-3.1/
>> readline-5.1 have fixed the issue or not.  I also don't have
>> access to a debian machine to try reproducing it myself.
>> 
>> -------------- Forwarded Message: --------------
>> From: Christopher Faylor <cgf-no-personal-reply-please@cygwin.com>
>> To: cygwin@cygwin.com
>> Subject: Re: Please try a snapshot - final push for 1.5.19
>> Date: Fri, 23 Dec 2005 21:45:56 +0000
>>> 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.
>>>
>>> In fact, I could crash bash on linux by doing a:
>>>
>>>   while kill -INT nnn; do :; done
>>>
>>> where nnn denotes the pid of a running Debian bash 3.00.16(1)-release
>>> binary.
>
>I fixed it.  The problem was that readline needs to block delivery of
>the signals it sets handlers for while setting them, since it uses a
>single binary flag to indicate that it has initialized its entire set of
>signal handlers.
>
>The problem arises when a signal arrives for SIGINT just after
>readline has installed rl_signal_handler as its handler, but before
>any other signal handlers have been installed.  signals_set_flag is
>still 0.  rl_signal_handler handles SIGINT, but readline doesn't think
>it should be doing so, and never sets the handler back to the original
>in rl_clear_signals.  The subsequent kill() in rl_signal_handler
>causes the recursion.

That is exactly what I was seeing.  I was planning on submitting a more
formal bug report after the holidays but you beat me to it.

cgf