Re: [Bug-readline] [gdb FYI-patch] callback-mode readline-6.0 regression

[Chet Ramey]

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
server hangs.

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.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/