aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2020-08-24 19:44:53 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2020-08-24 19:44:53 -0400
commit60122dbef4eb01b634019bd71ef47dec8faab274 (patch)
tree41efea1fbc546fdb429f59216e8ea1267f628157 /gdb
parentc426fddb87d29034b50c2433e12a08aa23b7fb9f (diff)
downloadgdb-60122dbef4eb01b634019bd71ef47dec8faab274.zip
gdb-60122dbef4eb01b634019bd71ef47dec8faab274.tar.gz
gdb-60122dbef4eb01b634019bd71ef47dec8faab274.tar.bz2
gdb/testsuite: make runto always emit a FAIL on internal error
I noticed that when a test uses `runto_main` and a GDB internal error happens while running to main, no error or fail is emitted. This is because `runto_main` uses the `no-message` option of `runto`. As a result, if a test fails to run to main and exits, no sign that something went wrong is emitted. For example, add this always-false assertion to compute_frame_id: --- a/gdb/frame.c +++ b/gdb/frame.c @@ -545,6 +545,7 @@ static void compute_frame_id (struct frame_info *fi) { gdb_assert (!fi->this_id.p); + gdb_assert (false); if (frame_debug) fprintf_unfiltered (gdb_stdlog, "{ compute_frame_id (fi=%d) ", ... and run gdb.dwarf2/dw2-align.exp. No fail or sign that something went wrong is shown. It just appears as if the test gets skipped. A developer introducing such a regression in this test today would likely notice it, because we are used to diff-ing test results. So we would see some PASSes dispappear for no good reason and look into it. But I find it worrysome for two reasons: 1. Scripts that analyze regressions (such as the one on the buildbot) may only look for new FAILs or new ERRORs. It would probably miss this. 2. Imagine that we one day have a testsuite that runs cleanly (some people might already run subsets of the testsuite and expect it to all pass), we would just run the testsuite and check that there are no fails. It would be easy to miss something like this. In case of internal error, I suggest making `runto` emit a FAIL even if `no-message` was passed. This is different from other failure modes that might be expected (whchi rightfully cause the test to simply be skipped). An internal error is always bad, so if it happens it should noisily fail. gdb/testsuite/ChangeLog: * lib/gdb.exp (runto): Always emit fail on internal error. Change-Id: I6e6faed4868ea821541a23042b2d01c30058b0d3
Diffstat (limited to 'gdb')
-rw-r--r--gdb/testsuite/ChangeLog4
-rw-r--r--gdb/testsuite/lib/gdb.exp6
2 files changed, 7 insertions, 3 deletions
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 61a37ab..b976a54 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-08-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ * lib/gdb.exp (runto): Always emit fail on internal error.
+
2020-08-24 Simon Marchi <simon.marchi@efficios.com>
* gdb.base/gdb-sigterm.exp (do_test): Update expected regexp.
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 5bdeed7..8ff2025 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -652,9 +652,9 @@ proc runto { function args } {
return 0
}
-re ".*A problem internal to GDB has been detected" {
- if { $print_fail } {
- fail "$test_name (GDB internal error)"
- }
+ # Always emit a FAIL if we encounter an internal error: internal
+ # errors are never expected.
+ fail "$test_name (GDB internal error)"
gdb_internal_error_resync
return 0
}