From 17f6581c36a82d849f1ece621e74cb7de0f3f0d4 Mon Sep 17 00:00:00 2001 From: Andrew Burgess Date: Sat, 2 Dec 2023 10:08:10 +0000 Subject: gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp The gdb.threads/thread-specific-bp.exp test has been a little problematic, see commits: commit 89702edd933a5595557bcd9cc4a0dcc3262226d4 Date: Thu Mar 9 12:31:26 2023 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver and commit 2e5843d87c4050bf1109921481fb29e1c470827f Date: Fri Nov 19 14:33:39 2021 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp But I recently saw a test failure for that test, which looked like this: ... (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected continue -a Continuing. Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 29 } (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited] Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout) ... This only crops up (for me) when running on a loaded machine, and still only occurs sometimes. I've had to leave the test running in a loop for 10+ minutes sometimes in order to see the failure. The problem is that we use gdb_test_multiple to try and match two patterns: (1) The 'Thread-specific breakpoint 3 deleted ....' message, and (2) The GDB prompt. As written in the test, we understand that these patterns can occur in any order, and we have a flag for each pattern. Once both patterns have been seen then we PASS the test. The problem is that once expect has matched a pattern, everything up to, and including the matched text is discarded from the input buffer. Thus, if the input buffer contains: Then expect will first try to match , which succeeds, and then expect discards the entire input buffer up to the end of the . As a result, we will never spot . Obviously we can't just reorder the patterns within the gdb_test_multiple, as the output can legitimately (and most often does) occur in the other order, in which case the test would mostly fail, and only occasionally pass! I think the easiest solution here is just to have the gdb_test_multiple contain two patterns, each pattern consists of the two parts, but in the alternative orders, thus, for a particular output configuration, only one regexp will match. With this change in place, I no longer see the intermittent failure. Approved-By: Tom Tromey --- gdb/testsuite/gdb.threads/thread-specific-bp.exp | 24 ++++++------------------ 1 file changed, 6 insertions(+), 18 deletions(-) (limited to 'gdb') diff --git a/gdb/testsuite/gdb.threads/thread-specific-bp.exp b/gdb/testsuite/gdb.threads/thread-specific-bp.exp index 8929f19..1f3b944 100644 --- a/gdb/testsuite/gdb.threads/thread-specific-bp.exp +++ b/gdb/testsuite/gdb.threads/thread-specific-bp.exp @@ -87,31 +87,19 @@ proc check_thread_specific_breakpoint {non_stop} { } else { set cmd "continue" } - set test "continue to end" - set thread_exited 0 - set prompt 0 set msg_re \ [join \ [list \ "Thread-specific breakpoint 3 deleted" \ "-" \ "thread 2 no longer in the thread list\\."]] - gdb_test_multiple "$cmd" $test -lbl { - -re "(^|\r\n)${msg_re}(?=\r\n)" { - if { $prompt } { - pass $gdb_test_name - } else { - set thread_exited 1 - exp_continue - } + + gdb_test_multiple "$cmd" "continue to end" { + -re "$\r\n${gdb_prompt} .*${msg_re}\r\n" { + pass $gdb_test_name } - -re "\r\n$gdb_prompt " { - if { $thread_exited } { - pass $gdb_test_name - } else { - set prompt 1 - exp_continue - } + -re "\r\n${msg_re}\r\n.*$gdb_prompt " { + pass $gdb_test_name } } -- cgit v1.1