[Bug gdb/26582] New: FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[Bug gdb/26582] New: FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26582

            Bug ID: 26582
           Summary: FAIL: gdb.base/hbreak2.exp: next over recursive call
                    (timeout)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

This started to fail for me reliably on opensuse tumbleweed in a vm with 1 cpu
at 75% exec cap:
...
FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)
FAIL: gdb.base/hbreak2.exp: backtrace from factorial(5.1) (timeout)
FAIL: gdb.base/hbreak2.exp: continue until exit at recursive next test
(timeout)
...

First FAIL in more detail:
...
(gdb) PASS: gdb.base/hbreak2.exp: backtrace from factorial(5)
next^M
64              value *= factorial (value - 1);^M
(gdb) PASS: gdb.base/hbreak2.exp: next to recursive call
delete breakpoints^M
Delete all breakpoints? (y or n) y^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) next^M
FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)
...

Reproduce on command line:
...
$ gdb \
    -batch \
    outputs/gdb.base/hbreak2/hbreak2 \
    -ex start \
    -ex "hbreak factorial" \
    -ex "info break" \
    -ex kill \
    -ex run \
    -ex cont \
    -ex next \
    -ex "delete breakpoints" \
    -ex "info break" \
    -ex next
Temporary breakpoint 1 at 0x401169: file
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/break.c, line 43.

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdd18, envp=0x7fffffffdd28)
at break.c:43
43          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited
*/ /* set breakpoint 6 here */
Hardware assisted breakpoint 2 at 0x40120b: file break.c, line 63.
Num     Type           Disp Enb Address            What
2       hw breakpoint  keep y   0x000000000040120b in factorial at break.c:63
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 13895) killed]

Breakpoint 2, factorial (value=6) at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/break.c:63
63        if (value > 1) {  /* set breakpoint 7 here */

Breakpoint 2, factorial (value=5) at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/break.c:63
63        if (value > 1) {  /* set breakpoint 7 here */
64              value *= factorial (value - 1);
No breakpoints or watchpoints.
<hang>
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26582] FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26582

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
All in the same VM: I can reproduce this with a build from gdb-9-branch
branchpoint, as well as with system gdb 9.2.

The observed behaviour is that gdb for the next command does a proceed for the
target and then waits for the target to return. Meanwhile, the target just
spins:
...

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND    
13448 vries     20   0    3492    912    784 R 96.70 0.011   0:20.76 hbreak2   
                                                       ...

If we print the pc before and after we have:
...
pc             0x401211            0x401211 <factorial+17>
^C
Program received signal SIGINT, Interrupt.
factorial (value=4) at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/break.c:63
63        if (value > 1) {  /* set breakpoint 7 here */
pc             0x40120b            0x40120b <factorial+11>
...

While factorial looks like:
...
0000000000401200 <factorial>:

line 62:
  401200:       55                      push   %rbp
  401201:       48 89 e5                mov    %rsp,%rbp
  401204:       48 83 ec 10             sub    $0x10,%rsp
  401208:       89 7d fc                mov    %edi,-0x4(%rbp)

line 63:
  40120b:       83 7d fc 01             cmpl   $0x1,-0x4(%rbp)
  40120f:       7e 16                   jle    401227 <factorial+0x27>

line 64:
  401211:       8b 45 fc                mov    -0x4(%rbp),%eax
  401214:       83 e8 01                sub    $0x1,%eax
  401217:       89 c7                   mov    %eax,%edi
  401219:       e8 e2 ff ff ff          callq  401200 <factorial>

line 64:
  40121e:       8b 55 fc                mov    -0x4(%rbp),%edx
  401221:       0f af c2                imul   %edx,%eax
  401224:       89 45 fc                mov    %eax,-0x4(%rbp)

line 66:
  401227:       8b 45 fc                mov    -0x4(%rbp),%eax

line 67:
  40122a:       c9                      leaveq 
  40122b:       c3                      retq   
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26582] FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26582

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
I don't know how to get insight into why it's spinning.  I can't do a coredump
because gdb owns the ptrace handle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26582] FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26582

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, just observed the same set of FAILs at
https://build.opensuse.org/build/devel:gcc/openSUSE_Factory/x86_64/gdb:testsuite/_log

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26582] FAIL: gdb.base/hbreak2.exp: next over recursive call (timeout)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26582

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> This started to fail for me reliably on opensuse tumbleweed in a vm with 1
> cpu at 75% exec cap:

I installed tumbleweed on a laptop, and managed to reproduce, so this is no
virtualization problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.