This email originated as a conversation on the GDB list, which can be found here:
https://inbox.sourceware.org/gdb-patches/[email protected]/ 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 <[email protected]> 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/[email protected]/ 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
