public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb] gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp
@ 2023-04-27 12:57 Andrew Burgess
0 siblings, 0 replies; only message in thread
From: Andrew Burgess @ 2023-04-27 12:57 UTC (permalink / raw)
To: gdb-cvs
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7492eb9f544f708c1c43ed71be88a4ad82f2648e
commit 7492eb9f544f708c1c43ed71be88a4ad82f2648e
Author: Andrew Burgess <aburgess@redhat.com>
Date: Fri Mar 31 16:41:27 2023 +0100
gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp
I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
fail when run from a particular directory.
The test tries to find the number of the first internal breakpoint
using this proc:
proc get_first_maint_bp_num { } {
gdb_test_multiple "maint info break" "find first internal bp num" {
-re -wrap "(-\[0-9\]).*" {
return $expect_out(1,string)
}
}
return ""
}
The problem is, at the time we issue 'maint info break' there are both
internal breakpoint and non-internal (user created) breakpoints in
place. The user created breakpoints include the path to the source
file.
Sometimes, I'll be working from a directory that includes a number,
like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
matches the '-1' from 'blah-1'. In this case there's no significant
problem as it turns out that -1 is the number of the first internal
breakpoint.
Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
case the above pattern patches '-4' from 'blah-4'. It turns out this
is also not a problem -- the test doesn't actually need the first
internal breakpoint number, it just needs the number of any internal
breakpoint.
But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
which case the pattern above matches '-0' from 'blah-0', and in this
case the test fails - there is no internal breakpoint '-0'.
Fix this by spotting that the internal breakpoint numbers always
occurs after a '\r\n', and that they never start with a 0. Our
pattern becomes:
-re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
return $expect_out(1,string)
}
After this I'm no longer seeing any failures.
Reviewed-By: Tom Tromey <tom@tromey.com>
Diff:
---
gdb/testsuite/gdb.base/clear_non_user_bp.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.base/clear_non_user_bp.exp b/gdb/testsuite/gdb.base/clear_non_user_bp.exp
index 10e6efddc14..dc1557695bd 100644
--- a/gdb/testsuite/gdb.base/clear_non_user_bp.exp
+++ b/gdb/testsuite/gdb.base/clear_non_user_bp.exp
@@ -30,7 +30,7 @@
#
proc get_first_maint_bp_num { } {
gdb_test_multiple "maint info break" "find first internal bp num" {
- -re -wrap "(-\[0-9\]).*" {
+ -re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
return $expect_out(1,string)
}
}
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2023-04-27 12:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-27 12:57 [binutils-gdb] gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp Andrew Burgess
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).