MI and SIGINT

MI and SIGINT

[Hafiz Abid Qadeer]

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

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*&&,
int&&)
#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

Regards,
-- 
Hafiz Abid Qadeer
Mentor Embedded/CodeSourcery

Re: MI and SIGINT

[Andrew Burgess]

* Hafiz Abid Qadeer <abid_qadeer@mentor.com> [2020-07-14 12:03:11 +0100]:

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

I don't have time to test this right now, but if your diagnosis is
correct then this should be easy to test.  Write a sniffer that sends
itself a SIGINT and check you see the problem.

This should make it possible to create a reliable test case.

Thanks,
Andrew


> 
> 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*&&,
> int&&)
> #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
> 
> Regards,
> -- 
> Hafiz Abid Qadeer
> Mentor Embedded/CodeSourcery

Re: MI and SIGINT

[Hafiz Abid Qadeer]

On 14/07/2020 19:58, Andrew Burgess wrote:
> * Hafiz Abid Qadeer <abid_qadeer@mentor.com> [2020-07-14 12:03:11 +0100]:
> 
>> 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
>> observers.
>> 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
>> message.
> 
> I don't have time to test this right now, but if your diagnosis is
> correct then this should be easy to test.  Write a sniffer that sends
> itself a SIGINT and check you see the problem.
> 
> This should make it possible to create a reliable test case.

I looked at bit more at it and it seems the behavior is intentional and
was added in 9ccabccd15603dbf9fe988c86708fe644d1398a7. If the ctrl-c
arrives while python unwinders are running then its translated to a quit
exception when back inside gdb.

In MI case, this quit exception can cause MI stop message not being
printed. I wonder if this should be classified as a defect or
intentional behavior considering the following in the documentation.

"An interrupt (often Ctrl-c) does not exit from GDB, but rather
terminates the action of any GDB command that is in progress and returns
to GDB command level. It is safe to type the interrupt character at any
time because GDB does not allow it to take effect until a time when it
is safe."

https://www.sourceware.org/gdb/onlinedocs/gdb.html#Quitting-GDB

Thanks,
-- 
Hafiz Abid Qadeer
Mentor Embedded/CodeSourcery