Bug 15297

Summary:	CTRL-C with set debug remote often crashes GDB
Product:	gdb	Reporter:	Jan Kratochvil <jan>
Component:	remote	Assignee:	Jan Kratochvil <jan>
Status:	RESOLVED FIXED
Severity:	normal	CC:	jan, pedro, tromey
Priority:	P2
Version:	HEAD
Target Milestone:	14.1
Host:	x86_64-unknown-linux-gnu	Target:
Build:		Last reconfirmed:
Bug Depends on:	14408
Bug Blocks:	15358

Description Jan Kratochvil 2013-03-22 18:08:30 UTC

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

Comment 1 Tom Tromey 2013-03-25 16:10:18 UTC

See also PR 14408.
SIGINT handling in remote.c needs an overhaul.

Comment 2 Jan Kratochvil 2013-06-25 07:31:18 UTC

Check also currently FAILing: gdb.base/random-signal.exp

Comment 3 Tom Tromey 2013-06-25 10:37:58 UTC

> Check also currently FAILing: gdb.base/random-signal.exp

How can I make it fail?

Comment 4 Jan Kratochvil 2013-06-25 11:45:54 UTC

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)
-----------------------------------------------------------------

Comment 5 Jan Kratochvil 2013-07-03 05:31:32 UTC

[patchv2 2/2] Fix CTRL-C for remote.c (PR remote/15297)
http://sourceware.org/ml/gdb-patches/2013-06/msg00943.html

Comment 6 Pedro Alves 2016-04-13 10:29:23 UTC

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.

Comment 7 Pedro Alves 2023-02-15 21:34:25 UTC

> 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.