4

I am debugging a new thread library, in which I set the stack register rsp manually (to switch to a user-managed stack), and then invoke a function which never returns.

When I try to get a backtrace in gdb, I get the following output.

(gdb) bt
#0  load (_m=std::memory_order_seq_cst, this=<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>)
    at /usr/include/c++/4.9/atomic:209
#1  Arachne::schedulerMainLoop () at Arachne.cc:236
#2  0x000000000040268d in Arachne::threadMainFunction (id=<optimized out>) at Arachne.cc:135
#3  0x0000000000000000 in ?? ()

How does gdb determine that the stack has 0 elements in it?

More generally, how does gdb determine how many elements the stack has?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
merlin2011
  • 71,677
  • 44
  • 195
  • 329
  • [frame pointers](https://en.wikipedia.org/wiki/Call_stack#Stack_and_frame_pointers) – n. m. could be an AI Jun 15 '16 at 06:56
  • https://sourceware.org/gdb/wiki/Internals%20Stack-Frames could be helpful – Inian Jun 15 '16 at 06:59
  • it may differ if you have 32 bit or 64 bit – Thomas Weller Jun 15 '16 at 07:00
  • On x86-64 Linux, backtracing / exception-handling stack unwinding relies on metadata in the `.eh_frame_hdr` section. Frame pointers are completely optional, and may not be used even if code is compiled with `-fno-omit-frame-pointer`. See http://stackoverflow.com/questions/14091231/what-do-the-eh-frame-and-eh-frame-hdr-sections-store-exactly and http://stackoverflow.com/questions/34055891/implementing-stack-backtrace-without-using-ebp. Please have a look at those and see if either this is a dup of either. There were more search hits for `.eh_frame_hdr`. – Peter Cordes Jun 15 '16 at 09:37
  • Sorry I'm being lazy and not taking the time to figure out which one is the best dup target myself, but I've never had to dig into the details myself. I just know that there is metadata generated by the compiler. I should probably look up how to generate the same metadata for hand-written asm functions sometime, though. Anyway, hopefully this clue is enough for you to be able to find the answer yourself. IDK how gdb figures out that it's reached the end of the unwinding. But maybe when it looks for another return address to index the metadata, and it finds something bogus. – Peter Cordes Jun 15 '16 at 09:43

1 Answers1

1

Asked for position 0 of stack, stack only has 0 elements on it. comes from gdb/dwarf2/expr.c and doesn't refer to your CPU stack. Instead, it complains about the stack that DWARF expressions work on.

This might mean that your DWARF debug info is invalid. Or what you did with esp confused GDB's DWARF expression evaluator.

0xF
  • 3,214
  • 1
  • 25
  • 29