This is the mail archive of the
mailing list for the GDB project.
Re: [Bug-readline] [gdb FYI-patch] callback-mode readline-6.0 regression
- From: Chet Ramey <chet dot ramey at case dot edu>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: bug-readline at gnu dot org, gdb-patches at sourceware dot org, chet dot ramey at case dot edu
- Date: Sun, 29 Nov 2009 19:30:07 -0500
- Subject: Re: [Bug-readline] [gdb FYI-patch] callback-mode readline-6.0 regression
- References: <20091129221908.GA12364@host0.dyn.jankratochvil.net>
- Reply-to: chet dot ramey at case dot edu
Jan Kratochvil wrote:
> Hi Chet,
> FSF GDB currently ships bundled with readline-5.2 which works fine.
> But using --with-system-readline and readline-6.0-patchlevel4 has
> a regression:
> readline-5.2: Run `gdb -nx -q' and type CTRL-C:
> (gdb) Quit
> (gdb) _
> readline-6.0: Run `gdb -nx -q' and type CTRL-C:
> (gdb) _
> = nothing happens (it gets buffered and executed later)
> (It does also FAIL on gdb.gdb/selftest.exp.)
> It is because GDB waits in its own poll() mainloop and readline uses via
> rl_callback_handler_install and rl_callback_handler_remove. This way the
> readline internal variable _rl_interrupt_immediately remains 0 and CTRL-C gets
> only stored to _rl_caught_signal but not executed.
Yes, you're right. The asynchronous signal handling mechanism readline 6
introduced (prompted, ironically, by a Red Hat bug report :-) ) doesn't
interact well with the callback interface.
> Seen in rl_signal_handler even if _rl_interrupt_immediately is set and
> _rl_handle_signal is called then the signal is still stored to
> _rl_caught_signal. In the _rl_interrupt_immediately case it should not be
> stored when it was already processed.
> rl_signal_handler does `_rl_interrupt_immediately = 0;' - while I am not aware
> of its meaning it breaks the nest-counting of other routines which do
> `_rl_interrupt_immediately++;' and `_rl_interrupt_immediately--;' possibly
> creating problematic `_rl_interrupt_immediately == -1'.
In practice, these are not problems. The signals readline catches are
usually ones that cause the calling application to either exit or jump
back to a main processing loop, but I will make the changes you suggest
because they make the code more correct.
_rl_interrupt_immediately is an internal mechanism to short-circuit the
asynchronous signal handling, used in cases where readline potentially
goes to read from the file system. It's intended to allow the application
to be interrupted if, for instance, a directory read from an NFS file
Since readline-6.1 is very late in its development cycle, the best thing
to do is to restore the readline-5.x behavior by testing for
RL_ISSTATE(RL_STATE_CALLBACK) in rl_signal_handler. Once readline-6.1 is
out, I can figure out whether that's the best approach.
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU firstname.lastname@example.org http://cnswww.cns.cwru.edu/~chet/