This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch] improve hand-call-in-threads.exp failure handling
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 6 Sep 2015 16:44:28 -0600
- Subject: [patch] improve hand-call-in-threads.exp failure handling
- Authentication-results: sourceware.org; auth=none
I've been looking at some apparent regressions in nios2-linux-gnu
gdbserver testing involving gdb.threads/hand-call-in-threads.exp. It is
failing to stop at the breakpoint after switching to thread 2, with the
result that all subsequent tests are timing out because we've lost the
gdb prompt while the target is stuck running an infinite loop. Getting
30 more timeouts after the initial failure only slows down testing and
doesn't provide any useful information, so we might as well just give up
the first time.
Then I noticed that, while all these tests used to PASS, they weren't
really working, and never have, AFAICT. Here's an excerpt from the
oldest archived test results I have handy (from a 2012-vintage gdb):
(gdb) PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 1
thread 2
Thread ID 2 not known.
(gdb) PASS: gdb.threads/hand-call-in-threads.exp: prepare to make hand
call, thread 2
call hand_call()
Breakpoint 3, hand_call () at
gdb/testsuite/gdb.threads/hand-call-in-threads.c:78
78 }
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(hand_call) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 2
Looks like the breakpoint hit test only appears to PASS because the
"thread" command was unsuccessful and we're still in thread 1. And, the
.exp file doesn't do anything to confirm that the "thread" command was
successful. Nowadays the "thread" command really does switch threads
here, but the .exp file still doesn't verify that it worked.
This patch tightens up the handling of both failure modes. OK to commit
as a general testsuite robustness improvement?
This doesn't fix the broken nios2 behavior, of course. I'm still
scratching my head.... kernel bug or something missing from the
gdbserver target back end? :-S
-Sandra
2015-09-06 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.threads/hand-call-in-threads.exp: Make sure the thread
command actually switches threads. Give up on remaining
tests if target fails to stop at breakpoint.
diff --git a/gdb/testsuite/gdb.threads/hand-call-in-threads.exp b/gdb/testsuite/gdb.threads/hand-call-in-threads.exp
index a9b90e1..64af511 100644
--- a/gdb/testsuite/gdb.threads/hand-call-in-threads.exp
+++ b/gdb/testsuite/gdb.threads/hand-call-in-threads.exp
@@ -84,10 +84,25 @@ set total_nr_threads [expr $NR_THREADS + 1]
# Thread numbering in gdb is origin-1, so begin numbering at 1.
for { set i 1 } { $i <= $total_nr_threads } { incr i } {
set thread_nr $i
- gdb_test "thread $thread_nr" ".*" \
+ gdb_test "thread $thread_nr" \
+ ".*Switching to thread $thread_nr.*" \
"prepare to make hand call, thread $thread_nr"
- gdb_test "call hand_call()" "Breakpoint 3, .*" \
- "hand call, thread $thread_nr"
+ gdb_test_multiple "call hand_call()" "" {
+ -re "Breakpoint 3, .*$gdb_prompt $" {
+ pass "hand call, thread $thread_nr"
+ }
+ -re "$gdb_prompt $" {
+ fail "hand call, thread $thread_nr (got gdb prompt)"
+ }
+ timeout {
+ # If the target fails to stop at the breakpoint, it just ends
+ # up in an infinite loop in hand_call(). If this happens
+ # and we have lost the GDB prompt, no further tests in
+ # this file will work and there is no point in continuing.
+ fail "hand call, thread $thread_nr (runaway target)"
+ return 0
+ }
+ }
}
# Now have each hand-called function return.