Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a C program that seg faults after descending deep into an infinite recursive mess. Backtracing the process in GDB is useless because the call stack frame is at least 1000 frames deep, and the repeated function calls are series of four common recursive function calls (so breakpoints seem useless). Repeated calls to backtrace just reads out the four function names, over and over and over. It occurred to me that doing 'up' 'up' 'up'... would get me higher up, so I could see where this pattern first started occurring, but it seems that it would be more efficient to start from the topmost call stack frame and step down instead, because my hunch is that the infinite recursion starts early in the process. If the call stack had N frames total, I know I could just do

gdb>> up N

to get to the top of the stack (the Nth frame), but the problem is that I don't know N. Is there a command for finding the total number of frames in the call stack? Or, is there a slick built-in GDB command for jumping to the topmost frame? It occurred to me that the topmost frame should be the main() function - can I leverage that knowledge to get to the topmost frame?

share|improve this question
up vote 6 down vote accepted

In my tests, using 'up' with a very large number resulted in the topmost frame being displayed, e.g.

(gdb) up 99999
#58 0x0000000000442fb4 in main ()
share|improve this answer
Thanks - that technique gets me to the topmost frame. – dandrews Jul 8 '11 at 17:04

You can specify 'bt' with a negative number to start from topmost frame:

bt -20

You can then use 'frame' (or 'f') to directly go to the frame you wish.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .