Use of rl_echo_signal_char in _rl_handle_signal

[Andrew Burgess]

This email originated as a conversation on the GDB list, which can be
found here:

  
https://inbox.sourceware.org/gdb-patches/20230518061046.17837-1-tdevries@suse.de/

The problem that was observed was that sometimes during testing GDB
would print '^C', but most of the time this would not happen.

The '^C' is printed from rl_echo_signal_char.

What normally happens is that the user types a character, GDB sees the
character appear on stdin and calls into readline to process the
character.  Once completed readline returns to GDB to await the next
event.  In this case the next event is the user typing 'Ctrl+c' which
sends SIGINT.  GDB's signal handler catches this and does its thing.

In the case where '^C' is printed though the user types a character and
we call into readline as before.  However, in this case, the user
manages to send the SIGINT after readline has printed the character to
stdout, but before readline has returned to GDB.  In this case the
signal is handled by readline signal handling, and we end up in
_rl_handle_signal which calls rl_echo_signal_char and then invokes GDB's
own signal handler.

The documentation for rl_echo_signal_char says:

     If an application wishes to install its own signal handlers, but
     still have readline display characters that generate signals,
     calling this function with SIG set to 'SIGINT', 'SIGQUIT', or
     'SIGTSTP' will display the character generating that signal.

I would also make the assumption that, when readline is used in callback
mode, the application spends most of its time with the applications
signal handlers installed, and only installs readline's handlers
occasionally.

My thinking then is that, for callback mode, readline should not call
rl_echo_signal_char from _rl_handle_signal.

If the applications wants to see '^C' then it will already call
rl_echo_signal_char as part of the signal processing, in which case
having readline call rl_echo_signal_char will mean we might sometimes
see a double '^C'.

And if the application doesn't want to see '^C' then calling
rl_echo_signal_char will mean readline sometimes prints some unwanted
output.

I do have a demo application which I used for investigating this issue.
I haven't included it in this email, but am happy to post it if that
helps at all, just let me know.

The patch below is my proposed fix to readline for your consideration.

Thanks,
Andrew

---

commit 676de63701ec1e383f6fd481a1c35d012475898b
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Thu Jun 1 11:21:04 2023 +0100

    readline: don't call rl_echo_signal_char when in callback mode
    
    This patch was a result of some GDB work that is discussed in this
    thread:
    
      
https://inbox.sourceware.org/gdb-patches/20230518061046.17837-1-tdevries@suse.de/

diff --git a/signals.c b/signals.c
index ec835e5..a95235d 100644
--- a/signals.c
+++ b/signals.c
@@ -267,7 +267,9 @@ _rl_handle_signal (int sig)
        sigprocmask (SIG_BLOCK, &set, &oset);
 #endif
 
+#if !defined (READLINE_CALLBACKS)
       rl_echo_signal_char (sig);
+#endif
       rl_cleanup_after_signal ();
 
       /* At this point, the application's signal handler, if any, is the