[Bug gdb/27702] New: Starting an inferior clears the dummy frames of all inferiors

[Bug gdb/27702] New: Starting an inferior clears the dummy frames of all inferiors

[simark at simark dot ca]

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

            Bug ID: 27702
           Summary: Starting an inferior clears the dummy frames of all
                    inferiors
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

The inferior_created observer of dummy-frame, function cleanup_dummy_frames,
clears all dummy frames.  I think this is a problematic if:

1. You start inferior 1, put a breakpoint on foo, and do "print foo()". 
inferior 1 is stopped and there exists a dummy frame on its stack
2. You add another inferior and start it (which invokes the inferior_created
observable)
3. The dummy frame list is cleared, which is a problem for inferior 1

Here's an illustration:

$ ./gdb -q -nx --data-directory=data-directory other
Reading symbols from other...
(gdb) start
Temporary breakpoint 1 at 0x1124: file other.c, line 6.
Starting program: /home/simark/build/binutils-gdb/gdb/other 

Temporary breakpoint 1, main () at other.c:6
6           return 0;
(gdb) b foo
Breakpoint 2 at 0x55555555511d: file other.c, line 3.
(gdb) p foo ()

Breakpoint 2, foo () at other.c:3
3       }
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(foo) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  foo () at other.c:3
#1  <function called from gdb>
#2  main () at other.c:6

Now, add the other inferior and start it:

(gdb) add-inferior 
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file other
Reading symbols from other...
(gdb) start
Temporary breakpoint 3 at 0x1124: -qualified main. (2 locations)
Starting program: /home/simark/build/binutils-gdb/gdb/other 

Thread 2.1 "other" hit Temporary breakpoint 3, main () at other.c:6
6           return 0;
(gdb) bt
#0  main () at other.c:6

Now let's check the backtrace of inferior 1:

(gdb) inferior 1
[Switching to inferior 1 [process 4128343]
(/home/simark/build/binutils-gdb/gdb/other)]
[Switching to thread 1.1 (process 4128343)]
#0  foo () at other.c:3
3       }
(gdb) bt
#0  foo () at other.c:3
#1  0x00007fffffffddbf in ?? ()
#2  0x0000000000000000 in ?? ()

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