aboutsummaryrefslogtreecommitdiff
path: root/zlib
diff options
context:
space:
mode:
authorKevin Buettner <kevinb@redhat.com>2023-02-27 16:11:37 -0700
committerKevin Buettner <kevinb@redhat.com>2023-02-27 16:20:39 -0700
commitb1ffd1124a8c5170a9e06b867a886b1138d28514 (patch)
treefa056267c77f2814bb43daf7f46423bf1da44ada /zlib
parent63509715af867d635ad0e8cfe5a662bfc67b4ddf (diff)
downloadgdb-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