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 <[EMAIL PROTECTED]> >> 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 _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
