This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug remote/15297] CTRL-C with set debug remote often crashes GDB


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]