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?

3 Answers 3


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 ()
  • 1
    Doesn't work if stack size is greater than 99999 Mar 24, 2017 at 22:31
  • This answer worked for me, just needed to use a bigger number.
    – tesch1
    Mar 29, 2018 at 14:53

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.


fr 0 will take you to the top-most stack frame. fr stands for frame.

  • 2
    that's the wrong direction
    – tesch1
    Mar 29, 2018 at 14:52
  • @tesch1 fair enough, but gdb backtrace shows you the bottom on top :) Mar 29, 2018 at 23:07

You must log in to answer this question.

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