Hafiz Abid Qadeer abid_qadeer@mentor.com
Tue Jul 14 11:03:11 GMT 2020

Hi All,
We have observed that a SIGINT send by an IDE can cause GDB to not print
MI stopped messages. Although this is very difficult to reproduce by
hand but the sequence look something like this.

1. You do continue and GDB hits a breakpoint and starts calling the
2. One of the observer will call into python sniffers.
3. If during that time, a SIGINT has arrived, it will cause python to
throw exception which will cause GDB to abandon printing the stopped

It is not a big problem in cli mode but can leave IDE in bit of limbo. I
was wondering if this is intended behavior with the SIGINT and MI.

The call stack of the exception looks like this:

#3  0x0000555555857ff1 in throw_quit
#4  0x00005555559b9bdb in gdbpy_print_stack_or_quit
#5  0x00005555559aa57f in pyuw_sniffer
#6  0x0000555555838a23 in frame_unwind_try_unwinder
#7  0x0000555555838b90 in frame_unwind_find_by_frame
#8  0x000055555583e7ad in get_frame_type
#9  0x0000555555a445e7 in print_frame_info
   #10 0x0000555555a42a9f in print_stack_frame
#11 0x00005555558b4ebe in print_stop_location
#12 0x00005555558b4f4b in print_stop_event
#13 0x000055555591ab17 in mi_on_normal_stop_1
#14 0x000055555591ad34 in mi_on_normal_stop
#15 0x0000555555618517 in std::_Function_handler<void (bpstats*, int),
void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&,
#16 0x00005555558b9d82 in std::function<void (bpstats*,
int)>::operator()(bpstats*, int) const
#17 0x00005555558b93db in gdb::observers::observable<bpstats*, int>::notify
#18 0x00005555558b5832 in normal_stop

Hafiz Abid Qadeer
Mentor Embedded/CodeSourcery

More information about the Gdb mailing list