This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug remote/15297] CTRL-C with set debug remote often crashes GDB
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 13 Apr 2016 10:29:23 +0000
- Subject: [Bug remote/15297] CTRL-C with set debug remote often crashes GDB
- Auto-submitted: auto-generated
- References: <bug-15297-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15297
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.