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

["blarsen at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.