async_remote_interrupt and async_remote_interrupt_twice are not signal-safe, they call functions including stdio. "set debug remote 1" makes the crash easily reproducible but the code is unsafe even without it. #0 __lll_lock_wait_private at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 in _L_lock_12203 at malloc.c:5144 #2 in __GI___libc_malloc at malloc.c:2860 #3 in _IO_vasprintf at vasprintf.c:50 #4 in xstrvprintf at ./common/common-utils.c:130 #5 in vfprintf_unfiltered at utils.c:2341 #6 in fprintf_unfiltered at utils.c:2394 #7 in async_remote_interrupt at remote.c:4942 #8 in call_async_signal_handler at event-loop.c:957 #9 in gdb_call_async_signal_handler at posix-hdep.c:64 #10 in remote_interrupt at remote.c:4981 #11 <signal handler called> #12 in _int_malloc at malloc.c:3721 #13 in __GI___libc_malloc at malloc.c:2863 #14 in mallochook at mcheck.c:223 #15 in _IO_vasprintf at vasprintf.c:50 #16 in xstrvprintf at ./common/common-utils.c:130 #17 in vfprintf_unfiltered at utils.c:2341 #18 in fprintf_unfiltered at utils.c:2394 #19 in printchar at utils.c:1625 #20 in fputstrn_unfiltered at utils.c:1665 #21 in escape_buffer at remote.c:7099 #22 in getpkt_or_notif_sane_1 at remote.c:7620 #23 in getpkt_or_notif_sane at remote.c:7675 #24 in remote_wait_as at remote.c:5880 #25 in remote_wait at remote.c:5997 #26 in target_wait at target.c:2646 #27 in wait_for_inferior at infrun.c:2732 #28 in proceed at infrun.c:2324 #29 in step_once at infcmd.c:1092 #30 in step_1 at infcmd.c:927 #31 in step_command at infcmd.c:847 #32 in do_cfunc at ./cli/cli-decode.c:113 #33 in cmd_func at ./cli/cli-decode.c:1857 #34 in execute_command at top.c:486
See also PR 14408. SIGINT handling in remote.c needs an overhaul.
Check also currently FAILing: gdb.base/random-signal.exp
> Check also currently FAILing: gdb.base/random-signal.exp How can I make it fail?
http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration DEJAGNU=$HOME/src/runtest-gdbserver/site.exp runtest --target_board native-gdbserver gdb.base/random-signal.exp But that is correct, making remote.c+gdbserver correctly breakable is what the pending patches of mine + Pedro are about. http://sourceware.org/ml/gdb-patches/2013-06/msg00363.html http://sourceware.org/ml/gdb-patches/2013-05/msg00933.html Just so far there was no testcase affected by this remote.c+gdbserver bug. You have implemented first testcase affected by it. FYI I get randomly the following three cases: ----------------------------------------------------------------- continue^M Continuing.^M PASS: gdb.base/random-signal.exp: continue ^C^M Program received signal SIGINT, Interrupt.^M main () at ./gdb.base/random-signal.c:28^M 28 ;^M (gdb) PASS: gdb.base/random-signal.exp: stop with control-c ----------------------------------------------------------------- continue^M Continuing.^M PASS: gdb.base/random-signal.exp: continue ^Cmain () at ./gdb.base/random-signal.c:28^M 28 ;^M Quit^M (gdb) FAIL: gdb.base/random-signal.exp: stop with control-c ----------------------------------------------------------------- continue^M Continuing.^M PASS: gdb.base/random-signal.exp: continue ^CFAIL: gdb.base/random-signal.exp: stop with control-c (timeout) -----------------------------------------------------------------
[patchv2 2/2] Fix CTRL-C for remote.c (PR remote/15297) http://sourceware.org/ml/gdb-patches/2013-06/msg00943.html
This should is largely fixed now: - immediate_quit is gone - the sync / async ctrl-chandling paths in remote.c are merged - we no longer do non-async-signal-safe things in the SIGINT handlers. - we should no longer get a "Quit" instead of a "Program received signal SIGINT". However, running Jan's test, on current master reveals we still have problems with a Ctrl-c coming in while Python code is running: infrun: clear_proceed_status_thread (Thread 15823.15823) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) Sending packet: $Z0,7ffff774d943,1#88...Packet received: OK Sending packet: $Z0,7ffff782d4e3,1#b3...Packet received: OK Sending packet: $Z0,7ffff7ddf908,1#e8...Packet received: OK Sending packet: $Z0,7ffff7df04e5,1#e1...Packet received: OK Sending packet: $Z0,7ffff7df1087,1#b3...Packet received: OK infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 15823.15823] at 0x4005e4 Sending packet: $vCont;s:p3dcf.3dcf#50...Packet received: OK infrun: prepare_to_wait Notification received: Stop:T0506:a0ccffffff7f0000;07:a0ccffffff7f0000;10:e405400000000000;thread:p3dcf.3dcf;core:4; Sending packet: $vStopped#55...Packet received: OK infrun: target_wait (-1.0.0, status) = infrun: 15823.15823.0 [Thread 15823.15823], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x4005e4 infrun: stepping inside range [0x4005e4-0x4005e6] infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 15823.15823] at 0x4005e4 Sending packet: $vCont;s:p3dcf.3dcf#50...Packet received: OK run a bit #7 ^CPython Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>: infrun: stepping inside range [0x4005e4-0x4005e6] infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 15823.15823] at 0x4005e4 Sending packet: $vCont;s:p3dcf.3dcf#50...Packet received: OK infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait That "^CPython Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>: " is probably from the Python frame unwinder machinery. At that point the target has the terminal, and since 2f99e8fc9cb84ca80cfca6c119f1f22bbfd2a314 this should not have happened (Change SIGINT handler for extension languages only when target terminal is ours), but something's still not right over there. I suspect that it's because now remote.c uses the standard SIGINT handler, which calls set_quit_flag, which calls active_ext_lang->ops->set_quit_flag.
> However, running Jan's test, on current master reveals we still have problems > with a Ctrl-c coming in while Python code is running: > ... > > That "^CPython Exception <class 'KeyboardInterrupt'> <class > 'KeyboardInterrupt'>: " is probably from the Python frame unwinder machinery. > At that point the target has the terminal, and since > 2f99e8fc9cb84ca80cfca6c119f1f22bbfd2a314 this should not have happened (Change > SIGINT handler for extension languages only when target terminal is ours), but > something's still not right over there. I suspect that it's because now > remote.c uses the standard SIGINT handler, which calls set_quit_flag, which > calls active_ext_lang->ops->set_quit_flag. So I think this issue is finally fixed by this series: https://inbox.sourceware.org/gdb-patches/20230210233604.2228450-1-pedro@palves.net/T/#m79098ae4ed85a49c9693a47a0ad7a139f63d47dd There's a separate PR about Ctrl-C and Python unwinder during execution: https://sourceware.org/bugzilla/show_bug.cgi?id=26266 which is really the same thing, and I'm leaving that open, hoping for a testcase. So we can close this one.