public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "abidh at codesourcery dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug mi/26266] New: SIGINT can cause GDB to skip printing MI stop message. Date: Mon, 20 Jul 2020 14:17:35 +0000 [thread overview] Message-ID: <bug-26266-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=26266 Bug ID: 26266 Summary: SIGINT can cause GDB to skip printing MI stop message. Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: mi Assignee: unassigned at sourceware dot org Reporter: abidh at codesourcery dot com Target Milestone: --- Since 9ccabccd15603dbf9fe988c86708fe644d1398a7, if a ctrl-c is pressed when GDB is running python unwinder, it will make it throw quit exception. But it can happen that python unwinder was running because GDB was printing MI stop message (see the stack trace below). The quit exception will make gdb to skip printing that and MI user will be left in a limbo. The problem is difficult to reproduce by hand as ctrl-c needs to come at right time. I find that adding some sleep in _execute_unwinders gives a windows to press ctrl-c and it becomes easier to reproduce this problem with the following steps. 1. Build a target executable with a loop. 2. Run gdb in mi mode. 3. Put breakpoint in the loop so that it is hit repeatedly. When gdb hits the breakpoint, it will print the MI stopped message with reason as breakpoint-hit. 4. Give a continue command and the immediately after do ^C. You will notice that GDB will not print a stopped message in this case. This issue was also briefly discussed on the mailing list. https://sourceware.org/pipermail/gdb/2020-July/048794.html 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 -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2020-07-20 14:17 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-20 14:17 abidh at codesourcery dot com [this message] 2023-02-15 21:19 ` [Bug mi/26266] " pedro at palves dot net
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=bug-26266-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@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: linkBe 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).