From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH] gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp
Date: Sat, 2 Dec 2023 10:31:04 +0000 [thread overview]
Message-ID: <1576cabe99ace298caa833800f40781be8404682.1701513033.git.aburgess@redhat.com> (raw)
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:
<PATTERN 2><PATTERN 1>
Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>. As a result, we will never spot <PATTERN 2>.
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.
---
.../gdb.threads/thread-specific-bp.exp | 24 +++++--------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/thread-specific-bp.exp b/gdb/testsuite/gdb.threads/thread-specific-bp.exp
index 8929f194844..1f3b9441202 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
}
}
base-commit: a393b155174d20d3d120b5012b87c5438ab9e3d4
--
2.25.4
next reply other threads:[~2023-12-02 10:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-02 10:31 Andrew Burgess [this message]
2023-12-15 19:21 ` Tom Tromey
2023-12-18 11:16 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1576cabe99ace298caa833800f40781be8404682.1701513033.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).