Re: readline signal bug

[Chet Ramey]

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.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live Strong.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/