Created attachment 14607 [details] 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.
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
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.