From: Andrew Burgess <aburgess@redhat.com>
To: Edgar Mobile <heideggm@hotmail.com>,
"gdb\@sourceware.org" <gdb@sourceware.org>
Subject: Re: Have GDB exit on SIGABRT
Date: Fri, 11 Feb 2022 11:16:55 +0000 [thread overview]
Message-ID: <871r09fyag.fsf@redhat.com> (raw)
In-Reply-To: <DM8PR16MB43575D10A387D637C4133722C7309@DM8PR16MB4357.namprd16.prod.outlook.com>
Edgar Mobile via Gdb <gdb@sourceware.org> writes:
> I want to start a gdb session for a process within a test environment
> that executes some commands via script. The test environment is
> configured so that it sends a SIGABRT after ten minutes which was
> enough to end the original process. With a GDB session however it will
> cause gdb to halt there which means the overall process never stops.
My assumption here is that the SIGABRT is being sent to the inferior
(the thing you're debugging), not GDB. If the SIGABRT is sent direct to
GDB then that would kill GDB, which would cause the inferior to exit
too (assuming the inferior is started under GDB, and you're not
attaching.
> Is it possible to configure the setup so that GDB completely quits
> when a SIGABRT arrives?
I'd consider making use of `handle`[1], something like `handle SIGABRT
pass print nostop` will mean that when the SIGABRT arrives GDB will pass
the signal to the inferior, killing it.
Now you might be able to queue up an exit, something like this worked
for me:
gdb -ex 'file ~/tmp/loop.x' -ex 'handle SIGABRT pass print nostop' -ex 'run' -ex 'quit'
Where loop.x just runs forever. Then, when I send SIGABRT to loop.x the
'run' command finishes, and the 'quit' gets run, which quits GDB. You
could also replace the 'quit' with the -batch command line flag[2], but
that makes less sense if you're running the commands from a script I
think.
Finally, if your script is more involved, and you want more control for
when to quit gdb, you could consider using the Python API. The events
mechanism[3] would allow you to handle the inferior exiting, or you
could drop the use of 'handle' completely, and catch the stop event,
check if the stop is due to SIGABRT, and then quit GDB.
Hope some of this helps,
Thanks,
Andrew
[1] https://sourceware.org/gdb/onlinedocs/gdb/Signals.html#Signals
[2] https://sourceware.org/gdb/onlinedocs/gdb/Mode-Options.html#Mode-Options
[3] https://sourceware.org/gdb/onlinedocs/gdb/Events-In-Python.html#Events-In-Python
next prev parent reply other threads:[~2022-02-11 11:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 8:52 Edgar Mobile
2022-02-11 11:16 ` Andrew Burgess [this message]
2022-02-11 13:15 ` Edgar Mobile
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=871r09fyag.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb@sourceware.org \
--cc=heideggm@hotmail.com \
/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).