[PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp

[PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp

[Simon Marchi]

I got failures like this once on a CI:

    frame^M
    &"frame\n"^M
    ~"#0  child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M
    ~"33\t    dummy = !dummy; /* thread loop line */\n"^M
    ^done^M
    (gdb) ^M
    FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)

The problem is that the test expects the following regexp:

  ".*#0  0x.*"

And that typically works, when the output of the frame command looks
like:

  #0  0x00005555555551bb in child_sub_function () at ...

My theory is the following.  Whether or not the hexadecimal address is
printed (roughly) depends on whether the current PC is at the beginning
of a line.  So depending on where thread 2 was when GDB stopped it
(after thread 1 hit its breakpoint), we can get either output.

Strangely, I couldn't reproduce the failure by running the test in a
loop for a while.  Given that the loop in child_sub_function compiles to
just 6 instructions here, it should happen relatively often that GDB
ptrace stops the thread when it's on one of the instructions that
wouldn't print the hex.  That remains a mystery.

I'm still confident enough that this is the reason, so adjust the
regexps to not expect an hexadecimal prefix (0x) but a function name
instead (either child_sub_function or child_function).  That one is
always printed, and is also a good check that we are in the frame we
expect.

Note that for test "frame 5", we are showing a pthread frame (on my
system), so the function name is internal to pthread, not something we
can rely on.  In that case, it's almost certain that we are not at the
beginning of a line, or that we don't have debug info, so I think it's
fine to expect the hex prefix.

And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
test currently does), since we are showing thread 1, which has hit a
breakpoint placed at the beginning of a line.

Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90
---
 gdb/testsuite/gdb.mi/mi-cmd-user-context.exp | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
index d7417d5ea7c..592e7b600da 100644
--- a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
+++ b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
@@ -79,7 +79,7 @@ mi_gdb_test "thread" \
 
 # Check we're in frame 0.
 mi_gdb_test "frame" \
-    ".*#0  0x.*" \
+    ".*#0  .*child_sub_function .*" \
     "frame 1"
 
 # Ask about a different frame in the current thread, the current frame
@@ -93,7 +93,7 @@ mi_gdb_test "thread" \
     "info thread 6"
 
 mi_gdb_test "frame" \
-    ".*#0  0x.*" \
+    ".*#0  .*child_sub_function.*" \
     "frame 2"
 
 
@@ -108,7 +108,7 @@ mi_gdb_test "thread" \
     "info thread 7"
 
 mi_gdb_test "frame" \
-    ".*#0  0x.*" \
+    ".*#0  .*child_sub_function.*" \
     "frame 3"
 
 # Select a different frame in the current thread.  Despite the use of
@@ -123,7 +123,7 @@ mi_gdb_test "thread" \
     "info thread 8"
 
 mi_gdb_test "frame" \
-    ".*#1  0x.*" \
+    ".*#1  .*child_function.*" \
     "frame 4"
 
 # Similar to the previous test, but this time the --frame option is
-- 
2.35.1

Re: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp

[Andrew Burgess]

Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:

> I got failures like this once on a CI:
>
>     frame^M
>     &"frame\n"^M
>     ~"#0  child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M
>     ~"33\t    dummy = !dummy; /* thread loop line */\n"^M
>     ^done^M
>     (gdb) ^M
>     FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
>
> The problem is that the test expects the following regexp:
>
>   ".*#0  0x.*"
>
> And that typically works, when the output of the frame command looks
> like:
>
>   #0  0x00005555555551bb in child_sub_function () at ...
>
> My theory is the following.  Whether or not the hexadecimal address is
> printed (roughly) depends on whether the current PC is at the beginning
> of a line.  So depending on where thread 2 was when GDB stopped it
> (after thread 1 hit its breakpoint), we can get either output.
>
> Strangely, I couldn't reproduce the failure by running the test in a
> loop for a while.  Given that the loop in child_sub_function compiles to
> just 6 instructions here, it should happen relatively often that GDB
> ptrace stops the thread when it's on one of the instructions that
> wouldn't print the hex.  That remains a mystery.
>
> I'm still confident enough that this is the reason, so adjust the
> regexps to not expect an hexadecimal prefix (0x) but a function name
> instead (either child_sub_function or child_function).  That one is
> always printed, and is also a good check that we are in the frame we
> expect.
>
> Note that for test "frame 5", we are showing a pthread frame (on my
> system), so the function name is internal to pthread, not something we
> can rely on.  In that case, it's almost certain that we are not at the
> beginning of a line, or that we don't have debug info, so I think it's
> fine to expect the hex prefix.
>
> And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
> test currently does), since we are showing thread 1, which has hit a
> breakpoint placed at the beginning of a line.

All sounds reasonable.  LGTM.

Thanks,
Andrew

>
> Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90
> ---
>  gdb/testsuite/gdb.mi/mi-cmd-user-context.exp | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
> index d7417d5ea7c..592e7b600da 100644
> --- a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
> +++ b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp
> @@ -79,7 +79,7 @@ mi_gdb_test "thread" \
>  
>  # Check we're in frame 0.
>  mi_gdb_test "frame" \
> -    ".*#0  0x.*" \
> +    ".*#0  .*child_sub_function .*" \
>      "frame 1"
>  
>  # Ask about a different frame in the current thread, the current frame
> @@ -93,7 +93,7 @@ mi_gdb_test "thread" \
>      "info thread 6"
>  
>  mi_gdb_test "frame" \
> -    ".*#0  0x.*" \
> +    ".*#0  .*child_sub_function.*" \
>      "frame 2"
>  
>  
> @@ -108,7 +108,7 @@ mi_gdb_test "thread" \
>      "info thread 7"
>  
>  mi_gdb_test "frame" \
> -    ".*#0  0x.*" \
> +    ".*#0  .*child_sub_function.*" \
>      "frame 3"
>  
>  # Select a different frame in the current thread.  Despite the use of
> @@ -123,7 +123,7 @@ mi_gdb_test "thread" \
>      "info thread 8"
>  
>  mi_gdb_test "frame" \
> -    ".*#1  0x.*" \
> +    ".*#1  .*child_function.*" \
>      "frame 4"
>  
>  # Similar to the previous test, but this time the --frame option is
> -- 
> 2.35.1

Re: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp

[Tom de Vries]

On 4/4/22 11:03, Andrew Burgess via Gdb-patches wrote:
> Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> I got failures like this once on a CI:
>>
>>      frame^M
>>      &"frame\n"^M
>>      ~"#0  child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M
>>      ~"33\t    dummy = !dummy; /* thread loop line */\n"^M
>>      ^done^M
>>      (gdb) ^M
>>      FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
>>
>> The problem is that the test expects the following regexp:
>>
>>    ".*#0  0x.*"
>>
>> And that typically works, when the output of the frame command looks
>> like:
>>
>>    #0  0x00005555555551bb in child_sub_function () at ...
>>
>> My theory is the following.  Whether or not the hexadecimal address is
>> printed (roughly) depends on whether the current PC is at the beginning
>> of a line.  So depending on where thread 2 was when GDB stopped it
>> (after thread 1 hit its breakpoint), we can get either output.
>>
>> Strangely, I couldn't reproduce the failure by running the test in a
>> loop for a while.  Given that the loop in child_sub_function compiles to
>> just 6 instructions here, it should happen relatively often that GDB
>> ptrace stops the thread when it's on one of the instructions that
>> wouldn't print the hex.  That remains a mystery.
>>
>> I'm still confident enough that this is the reason, so adjust the
>> regexps to not expect an hexadecimal prefix (0x) but a function name
>> instead (either child_sub_function or child_function).  That one is
>> always printed, and is also a good check that we are in the frame we
>> expect.
>>
>> Note that for test "frame 5", we are showing a pthread frame (on my
>> system), so the function name is internal to pthread, not something we
>> can rely on.  In that case, it's almost certain that we are not at the
>> beginning of a line, or that we don't have debug info, so I think it's
>> fine to expect the hex prefix.
>>
>> And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
>> test currently does), since we are showing thread 1, which has hit a
>> breakpoint placed at the beginning of a line.
> 
> All sounds reasonable.  LGTM.
> 

Hi,

I'd like to mention this PR ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=29025 ) I've just filed.

AFAICT it's a slightly different variant of the problem that you're 
addressing here: the thread is not stopped in child_sub_function, but 
even earlier.  So, I'd say you could update the patch to handle that 
case as well, or leave it for a follow-up commit.

Thanks,
- Tom

Re: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp

[Simon Marchi]

> Hi,
>
> I'd like to mention this PR ( https://sourceware.org/bugzilla/show_bug.cgi?id=29025 ) I've just filed.
>
> AFAICT it's a slightly different variant of the problem that you're addressing here: the thread is not stopped in child_sub_function, but even earlier.  So, I'd say you could update the patch to handle that case as well, or leave it for a follow-up commit.

Ok, good point, let's see if we can fix this at the same time.

I posted a v2 here:

  https://sourceware.org/pipermail/gdb-patches/2022-April/187353.html

Simon