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).