aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-07-21 18:23:19 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-08-11 12:35:15 +0100
commit0e6e4b599a1572823c71e2e95a24cf17d048f42b (patch)
tree4440aa092ad2b38dbf70c818814bb8fcda47a302
parentd03277b79793adec2508d51f8d789cd3761d9b9d (diff)
downloadfsf-binutils-gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.zip
fsf-binutils-gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.tar.gz
fsf-binutils-gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.tar.bz2
gdb: don't print backtrace when dumping core after an internal error
Currently, when GDB hits an internal error, and the user selects to dump core, the recently added feature to write a backtrace to the console will kick in, and print a backtrace as well as dumping the core. This was certainly not my intention when adding the backtrace on fatal signal functionality, this feature was intended to produce a backtrace when GDB crashes due to some fatal signal, internal errors should have continued to behave as they did before, unchanged. In this commit I set the signal disposition of SIGABRT back to SIG_DFL just prior to the call to abort() that GDB uses to trigger the core dump, this prevents GDB reaching the code that writes the backtrace to the console. I've also added a test that checks we don't see a backtrace on the console after an internal error.
-rw-r--r--gdb/testsuite/gdb.base/bt-on-fatal-signal.exp36
-rw-r--r--gdb/utils.c5
2 files changed, 41 insertions, 0 deletions
diff --git a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
index 8875d00..1f0d61f 100644
--- a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
+++ b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp
@@ -135,3 +135,39 @@ foreach test_data {{SEGV "Segmentation fault"} \
gdb_exit
}
}
+
+# Check that when we get an internal error and choose to dump core, we
+# don't print a backtrace to the console.
+with_test_prefix "internal-error" {
+ # Restart GDB.
+ clean_restart $binfile
+
+ set saw_bt_start false
+
+ gdb_test_multiple "maint internal-error foo" "" {
+ -early -re "internal-error: foo\r\n" {
+ exp_continue
+ }
+ -early -re "^A problem internal to GDB has been detected,\r\n" {
+ exp_continue
+ }
+ -early -re "^further debugging may prove unreliable\\.\r\n" {
+ exp_continue
+ }
+ -early -re "^Quit this debugging session\\? \\(y or n\\)" {
+ send_gdb "y\n"
+ exp_continue
+ }
+ -early -re "^Create a core file of GDB\\? \\(y or n\\)" {
+ send_gdb "y\n"
+ exp_continue
+ }
+ -early -re "----- Backtrace -----\r\n" {
+ set saw_bt_start true
+ exp_continue
+ }
+ eof {
+ gdb_assert { [expr ! $saw_bt_start] }
+ }
+ }
+}
diff --git a/gdb/utils.c b/gdb/utils.c
index c59c635..1c226d5 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -201,6 +201,11 @@ dump_core (void)
setrlimit (RLIMIT_CORE, &rlim);
#endif /* HAVE_SETRLIMIT */
+ /* Ensure that the SIGABRT we're about to raise will immediately cause
+ GDB to exit and dump core, we don't want to trigger GDB's printing of
+ a backtrace to the console here. */
+ signal (SIGABRT, SIG_DFL);
+
abort (); /* ARI: abort */
}