Bug 29025 - [gdb/testsuite] FAIL: gdb.mi/mi-cmd-user-context.exp: frame {1,2,3} (unexpected output)
Summary: [gdb/testsuite] FAIL: gdb.mi/mi-cmd-user-context.exp: frame {1,2,3} (unexpect...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: testsuite (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-04 14:13 UTC by Tom de Vries
Modified: 2022-04-05 12:18 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2022-04-04 14:13:37 UTC 
While running the gdb testsuite for gdb-12-branch on openSUSE Tumbleweed, I ran into:
...
FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
FAIL: gdb.mi/mi-cmd-user-context.exp: frame 2 (unexpected output)
FAIL: gdb.mi/mi-cmd-user-context.exp: frame 3 (unexpected output)
...

I tried to reproduce, and managed by running in parallel with "stress -c 5", 4 times in a run of 25.

The first FAIL looks like this in more detail:
...
PASS: gdb.mi/mi-cmd-user-context.exp: info thread 5
Expecting: ^(frame[^M
]+)?(.*#0  .*child_sub_function .*[^M
]+[(]gdb[)] ^M
[ ]*)
frame^M
&"frame\n"^M
~"#0  0x00007ffff7d3049a in pthread_barrier_wait@GLIBC_2.2.5 () from /lib64/libc.so.6\n"\
^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
...

Reading through the source code, the behaviour makes sense.

A breakpoint is set in main, after the call to pthread_barrier_wait.

This guarantees that when the breakpoint is hit, all threads have reached the barrier, and guarantees that the main thread has left the barrier, but not that the other threads have left the barrier. 

So at first glance this looks like a testsuite problem.
Comment 1 Tom de Vries 2022-04-04 14:32:37 UTC 
(In reply to Tom de Vries from comment #0)
> While running the gdb testsuite for gdb-12-branch on openSUSE Tumbleweed, I
> ran into:
> ...
> FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
> FAIL: gdb.mi/mi-cmd-user-context.exp: frame 2 (unexpected output)
> FAIL: gdb.mi/mi-cmd-user-context.exp: frame 3 (unexpected output)
> ...
> 

Hm, actually the original FAIL was a reproduction of the problem fixed by this ( https://sourceware.org/pipermail/gdb-patches/2022-April/187319.html ):
...
PASS: gdb.mi/mi-cmd-user-context.exp: info thread 5
Expecting: ^(frame[^M
]+)?(.*#0  0x.*[^M
]+[(]gdb[)] ^M
[ ]*)
frame^M
&"frame\n"^M
~"#0  child_sub_function () at /data/vries/gdb_versions/devel/src/gdb/testsuite/gdb.mi/u\
ser-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 detailed FAIL listed in comment 0, is what I got when trying reproduce.