diff options
author | Kevin Buettner <kevinb@redhat.com> | 2023-02-27 16:11:37 -0700 |
---|---|---|
committer | Kevin Buettner <kevinb@redhat.com> | 2023-02-27 16:20:39 -0700 |
commit | b1ffd1124a8c5170a9e06b867a886b1138d28514 (patch) | |
tree | fa056267c77f2814bb43daf7f46423bf1da44ada /zlib | |
parent | 63509715af867d635ad0e8cfe5a662bfc67b4ddf (diff) | |
download | gdb-b1ffd1124a8c5170a9e06b867a886b1138d28514.zip gdb-b1ffd1124a8c5170a9e06b867a886b1138d28514.tar.gz gdb-b1ffd1124a8c5170a9e06b867a886b1138d28514.tar.bz2 |
Catch gdb_exception_error instead of gdb_exception (in many places)
As described in the previous commit for this series, I became
concerned that there might be instances in which a QUIT (due to either
a SIGINT or SIGTERM) might not cause execution to return to the top
level. In some (though very few) instances, it is okay to not
propagate the exception for a Ctrl-C / SIGINT, but I don't think that
it is ever okay to swallow the exception caused by a SIGTERM.
Allowing that to happen would definitely be a deviation from the
current behavior in which GDB exits upon receipt of a SIGTERM.
I looked at all cases where an exception handler catches a
gdb_exception. Handlers which did NOT need modification were those
which satisifed one or more of the following conditions:
1) There is no call path to maybe_quit() in the try block. I used a
static analysis tool to help make this determination. In
instances where the tool didn't provide an answer of "yes, this
call path can result in maybe_quit() being called", I reviewed it
by hand.
2) The catch block contains a throw for conditions that it
doesn't want to handle; these "not handled" conditions
must include the quit exception and the new "forced quit" exception.
3) There was (also) a catch for gdb_exception_quit.
Any try/catch blocks not meeting the above conditions could
potentially swallow a QUIT exception.
My first thought was to add catch blocks for gdb_exception_quit and
then rethrow the exception. But Pedro pointed out that this can be
handled without adding additional code by simply catching
gdb_exception_error instead. That's what this patch series does.
There are some oddball cases which needed to be handled differently,
plus the extension languages, but those are handled in later patches.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-by: Pedro Alves <pedro@palves.net>
Diffstat (limited to 'zlib')
0 files changed, 0 insertions, 0 deletions