[Bug record/30025] New: Adding an inferior when already recording corrupts the first inferior state

[Bug record/30025] New: Adding an inferior when already recording corrupts the first inferior state

[blarsen at redhat dot com]

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

            Bug ID: 30025
           Summary: Adding an inferior when already recording corrupts the
                    first inferior state
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: record
          Assignee: unassigned at sourceware dot org
          Reporter: blarsen at redhat dot com
  Target Milestone: ---

Created attachment 14607
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14607&action=edit
Minimal reproducer

When debugging an inferior whose execution is being recorded and a new inferior
is added, the original inferior's state seems to be corrupted somehow. As an
example, debugging the program attached to this bug I got the following
session:

$ ./gdb -q ~/a.out
Reading symbols from /home/blarsen/a.out...
(gdb) start
Temporary breakpoint 1 at 0x401137: file t.c, line 7.
Starting program: /home/blarsen/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at t.c:7
7           int q = 0;
(gdb) record
(gdb) n
8           fact(5);
(gdb) add-inferior -exec ~/a.out
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /home/blarsen/a.out...
(gdb) inferior 2
[Switching to inferior 2 [<null>] (/home/blarsen/a.out)]
(gdb) start
Temporary breakpoint 2 at 0x401137: -qualified main. (2 locations)
Starting program: /home/blarsen/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Thread 2.1 "a.out" hit Temporary breakpoint 2.2, main () at t.c:7
7           int q = 0;
(gdb) inferior 1
[Switching to inferior 1 [process 106244] (/home/blarsen/a.out)]
[Switching to thread 1.1 (Thread 0x7ffff7fa6600 (LWP 106244))]
#0  main () at t.c:8
8           fact(5);
(gdb) n

Thread 1.1 "a.out" received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000401115 in fact (n=1) at t.c:2
2           if (n<2) return n;


When the SIGTRAP happens isn't consistent, and sometimes it happens in a way
that seems to corrupt the parameter, I've seen values ranging from 32 thousand
to -17 thousand.

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

[Bug record/30025] Adding an inferior when already recording makes GDB not handle SIGTRAP correctly

[blarsen at redhat dot com]

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

B. Larsen <blarsen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Adding an inferior when     |Adding an inferior when
                   |already recording corrupts  |already recording makes GDB
                   |the first inferior state    |not handle SIGTRAP
                   |                            |correctly

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

[Bug record/30025] Adding an inferior when already recording makes GDB not handle SIGTRAP correctly

[blarsen at redhat dot com]

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

--- Comment #1 from B. Larsen <blarsen at redhat dot com> ---
Upon further inspection, its not nat the state of inferior 1 is corrupted.
Instead, GDB just doesn't handle the SIGTRAP correctly. Looking at the $PCs
when stepping to the factorial function, we have:

Program received signal SIGTRAP, Trace/breakpoint trap.                         
0x0000000000401107 in fact (n=32767) at t.c:1                                   
1       int fact(int n){                                                        
(gdb) p $pc                                                                     
$1 = (void (*)()) 0x401107 <fact+1>
(gdb) si
0x000000000040110a      1       int fact(int n){
(gdb) 
0x000000000040110e      1       int fact(int n){
(gdb) 
2           if (n<2) return n;
(gdb) p $pc
$2 = (void (*)()) 0x401111 <fact+11>

While the exact same session without recording inferior 1 looks like this:

(gdb) s
fact (n=5) at t.c:2
2           if (n<2) return n;
(gdb) p $pc
$1 = (void (*)()) 0x401111 <fact+11>

Seems clear to me that instead of continuing execution until we were at an
"is_stmt", GDB is just stopping at the instruction that received the sigtrap

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

[Bug record/30025] Adding an inferior when already recording makes GDB not handle SIGTRAP correctly

[blarsen at redhat dot com]

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

--- Comment #2 from B. Larsen <blarsen at redhat dot com> ---
It seems that this SIGTRAP doesn't always happen consistently. It often happens
on the second instruction of the function (since a SIGTRAP on the first
instruction is expected), but it can happen anywhere. I've had it anywhere
between 0x401107 and 0x40111f, and one or two times it didn't trigger at all.

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

[Bug record/30025] Adding an inferior when already recording makes GDB not handle SIGTRAP correctly

[blarsen at redhat dot com]

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

Guinevere Larsen <blarsen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |good-first-bug

--- Comment #3 from Guinevere Larsen <blarsen at redhat dot com> ---
Some change happened on upstream and this no longer happens. I'm changing this
to just ask for a test to confirm that this doesn't regress, which makes for a
pretty easy bug to start contributing.

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