On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote:
> Hi,
> Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the
> bash instance receiving them. Steps to reproduce:
> * Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
> * Launch another shell and send rapid SIGINTs: while true ; do kill -INT
> OTHER_PID; done
>
> SHELL_1 quickly dies with a SEGAULT
>
> Tested on GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu), compiled
> via plain ./configure && make
>
> Thanks and Kind Regards
> Tycho
I am able to reproduce this as well, on the latest devel version
(2610d40b32301cd7256bf1dfc49c9f8bfe0dcd53).
The shell crashes due to what seems runaway self-recursion while handling the
interrupt signal in readline:
$ gdb -c core ./bash -ex bt </dev/null | tail -n25
#78489 0x0000557419f0a74e in _rl_signal_handler (sig=2) at signals.c:149
#78490 0x0000557419f0b0f0 in _rl_release_sigint () at signals.c:674
#78491 0x0000557419f06345 in rl_redisplay () at display.c:1671
#78492 0x0000557419f097ed in rl_clear_message () at display.c:3154
#78493 0x0000557419f0b06e in rl_free_line_state () at signals.c:620
#78494 0x0000557419f0a82f in _rl_handle_signal (sig=2) at signals.c:217
#78495 0x0000557419f0a74e in _rl_signal_handler (sig=2) at signals.c:149
#78496 0x0000557419f0f354 in rl_getc (stream=0x7f886046a8e0
<_IO_2_1_stdin_>) at input.c:942
#78497 0x0000557419f0f102 in rl_read_key () at input.c:816
#78498 0x0000557419eed750 in readline_internal_char () at readline.c:629
#78499 0x0000557419eedb1c in readline_internal_charloop () at readline.c:737
#78500 0x0000557419eedb3c in readline_internal () at readline.c:749
#78501 0x0000557419eecf92 in readline (prompt=0x5574202f1c30 "bash-5.3$ ")
at readline.c:387
#78502 0x0000557419e2097d in yy_readline_get () at ./parse.y:1629
#78503 0x0000557419e20a95 in yy_readline_get () at ./parse.y:1659
#78504 0x0000557419e208ad in yy_getc () at ./parse.y:1559
#78505 0x0000557419e21a89 in shell_getc (remove_quoted_newline=1) at
./parse.y:2489
#78506 0x0000557419e239e6 in read_token (command=0) at ./parse.y:3550
#78507 0x0000557419e22cfa in yylex () at ./parse.y:3016
#78508 0x0000557419e1d054 in yyparse () at y.tab.c:1902
#78509 0x0000557419e1c83e in parse_command () at eval.c:365
#78510 0x0000557419e1c933 in read_command () at eval.c:410
#78511 0x0000557419e1c22a in reader_loop () at eval.c:143
#78512 0x0000557419e19b8c in main (argc=1, argv=0x7ffe0622cbd8,
env=0x7ffe0622cbe8) at shell.c:834
On my system, it seems to crash at around the 13k-ieth call to
_rl_signal_handler:
$ gdb -c core ./bash -ex bt </dev/null | grep -c 0x0000557419f0a74e
13083
This problem seems to have been introduced in Bash 4.3, in commit
ac50fbac377e32b98d2de396f016ea81e8ee9961. Prior to this change, the observable
effect on the shell which receives a flood of interrupt signals is to redisplay
the prompt, with a varying amount of empty lines in between.
