public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Hafiz Abid Qadeer <abid_qadeer@mentor.com>
Cc: gdb@sourceware.org
Subject: Re: MI and SIGINT
Date: Tue, 14 Jul 2020 19:58:50 +0100	[thread overview]
Message-ID: <20200714185850.GI3463@embecosm.com> (raw)
In-Reply-To: <f047b97c-f27a-b7a7-fadd-8b864ae9647f@mentor.com>

* 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

  reply	other threads:[~2020-07-14 23:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 11:03 Hafiz Abid Qadeer
2020-07-14 18:58 ` Andrew Burgess [this message]
2020-07-17 15:28   ` Hafiz Abid Qadeer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200714185850.GI3463@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=abid_qadeer@mentor.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).