On 3/22/23 12:06 PM, Grisha Levit wrote:
On Wed, Mar 22, 2023 at 11:50 AM Chet Ramey <[email protected]> wrote:
Thanks for the report. It's the unusual application that receives a SIGINT
and doesn't at least jump back to the top level.
I might be misunderstanding, but I was only testing with bash, not any
other application.
I can't reproduce it with bash and command completion (that's the easiest
way to get more possible completions than the completion-query-items
limit) or filename completion on /usr/bin. This is on RHEL 9 without any
completions installed. It jumps back to PS1.
The call chain (current devel branch version) goes something like this:
get_y_or_n
rl_getc
pselect
SIGINT -> _rl_caught_signal = SIGINT -> pselect returns -1
back to rl_getc
RL_CHECK_SIGNALS
_rl_signal_handler -> _rl_handle_signal (SIGINT)
_rl_complete_sigcleanup -- this is where `matches' gets freed
[some other signal cleanup code]
[restore application signal handler]
kill (0, SIGINT)
sigint_sighandler (bash)
[bash signal cleanup code]
bashline_set_event_hook -> rl_signal_event_hook = bash_event_hook
back to _rl_handle_signal
[more cleanup code, returns from RL_CHECK_SIGNALS]
back to rl_getc
rl_getc calls bash_event_hook through rl_signal_event_hook
bash_event_hook calls check_signals_and_traps
throw_to_top_level -> longjmp(top_level)
reader_loop, which starts the whole readline() call chain again
There's a lot of work to avoid doing too much in signal handlers. There
have been changes since bash-5.2 was released, but I wasn't able to
reproduce it with bash-5.2.15, either.
Your change is reasonable, and I installed it, but I wasn't able to do
any before-and-after checking.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
