[Bug backtrace/22946] New: Frame command with multiple stacks broken

["niklas.reiners at gmx dot de" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 22946
           Summary: Frame command with multiple stacks broken
           Product: gdb
           Version: 8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: niklas.reiners at gmx dot de
  Target Milestone: ---

Created attachment 10883
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10883&action=edit
Main program

It appears that changing between several stacks with 'frame' is broken. I
prepared a example program and a python script to show this. A descriptions of
the test case and the problem including example output follow below. All the
material can also be found in this repository:
https://github.com/NotAC0W/gdb-switch-stacks


:::: Test case description
The program calls setup() which allocates space for a new stack on the heap,
prepares it and jumps to the new stack with a function to execute. This
function calls a function that calls another and then encounters 
a fabricated crash in this last function.

Loading backtracing_stacks.py into gdb adds the command 'bts' which prints the
bt for both stacks invoked from the point
of the fabricated crash.

:::: Simple call tree

. main() calls setup()
.. setup() allocates place for a new stack on the heap
.. setup() calls create_stack(stack, new_world) which
... puts new_world on that stack as return address
... saves several register and EFLAGS on that stack
.. setup() calls switch_stack()
... saves registers and EFLAGS on current register
... changes sp to new stack
... recovers EFLAGS and registers
... returns to new_world()

. new_world calls asmfoo()
.. asmfoo calls asmfoo2()
... asmfoo2 has a segfault build in that crashes the program 


:::: Problem description

Invoking the 'bts' on the crash will print the current stack, but will have a
"Invalid Frame" exception on printing the 
old stack.

The script first will print the current stack to show that working. Then it
will jump within that stack to another frame
with the same methodology that is used to jump to the other stack showing that
doing it within
the "current stack" works. Then it will selected the top frame on the other
stack and try to print that
stack which fails.

Setting a break point on main.c:26 and inspecting the stack pointer shows that
it is identical to the address determined 
by the script.


:::: Example output with GNU 8.1

$ gdb ./jumping_stacks 
Reading symbols from ./jumping_stacks...done.
(gdb) source backtracing_stacks.py 
(gdb) b main.c:26
Breakpoint 1 at 0x6ff: file main.c, line 26.
(gdb) r
Starting program: /home/user/gdb/jumping_stacks 
Switching Stack

Breakpoint 1, setup () at main.c:26
26              switch_stack(&old_stack, bottom-64); 
(gdb) print $rsp
$1 = (void *) 0x7fffffffe1c0
(gdb) c
Continuing.
Hello Ding Dong

Program received signal SIGSEGV, Segmentation fault.
asmfoo2 () at functions.S:14
14              movq %r12, 0(%r12) #This is intentionally broken
(gdb) bts
Current Stack:
#0 0x000055555555474a in None()+13 at functions.S:14
#1 0x000055555555475c in None()+31 at functions.S:32
#2 0x00005555555546a4 in new_world()+26 at main.c:15
Stopped because pc = 0

Attempting to jump frame 'within' stack
#0 0x000055555555475c in None()+31 at functions.S:32
#1 0x00005555555546a4 in new_world()+26 at main.c:15
Stopped because pc = 0

Attempting to jump frame 'outof' stack
Old Stack: 0x7fffffffe180 PC Address 0x55555555475f
Frameline is +64: 0x7fffffffe1c0
Switching Stacks: select-frame 0x7fffffffe1c0 0x55555555475f
Old Stack:
Python Exception <class 'gdb.error'> Frame is invalid.: 
Error occurred in Python command: Frame is invalid.

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