Have GDB exit on SIGABRT

Have GDB exit on SIGABRT

[Edgar Mobile via Gdb]

Greetings,

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.

Is it possible to configure the setup so that GDB completely quits when a SIGABRT arrives?

Regards

Re: Have GDB exit on SIGABRT

[Andrew Burgess via Gdb]

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

Re: Have GDB exit on SIGABRT

[Edgar Mobile via Gdb]

Will try thanks!

________________________________
From: Andrew Burgess <aburgess@redhat.com>
Sent: Friday, February 11, 2022 11:16 AM
To: Edgar Mobile <heideggm@hotmail.com>; gdb@sourceware.org <gdb@sourceware.org>
Subject: Re: Have GDB exit on SIGABRT

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