Getting a stack trace from GDB

Question

I must have a misunderstanding of the stack, or how functions are called, the backtrace results I'm getting from GDB make no sense to me. I'm trying to find out where things get called in a program so that I can add my component.

The tool draws bounding boxes on videos, what I made is an interpolator. I thought it only made sense to open GDB and put a breakpoint in when a box was being drawn, and run a backtrace. Here's mu output (after running the program from ffmpeg.c main())

#0  draw_glyphs (vidatbox=0x10183d200, picref=0x10141e340, width=720, height=480,
rgbcolor=0x10183d284 "????", yuvcolor=0x10183d278 "뀀?\020???\020???????", x=0, y=0) at 
libavfilter/vf_VidAT.c:627
#1  0x000000010001ce4c in draw_text (ctx=0x10120df20, picref=0x10141e340, width=720, 
height=480) at libavfilter/vf_VidAT.c:787

Disregarding all the non ascii chars,how are the two functions draw_glyphs and draw_text being called? How come there is nothing else on the stack? When I select Frame #1 and try and go up, it tells me:

Initial frame selected; you cannot go up.

EDIT:

I've looked more, and I'm even more confused then I was when I asked. The function draw_glyphs is not even called inside of the main that I'm running. I've grepped through all the files that this uses to compile and well...it's not called anywhere!

Does this mean that it's a dynamically created function pointer or something? If so, would that make the stack innaccessible like mine is?

Answer 1

If the stack trace is informative but terminates unexpectedly (especially after just one or two entries), then that indicates that gdb was unable to follow the call stack past that point.

Compiler options that interfere with stack unwinding include higher optimisation levels (esp. -O3) and -fomit-frame-pointer, so search your Makefiles and remove those options. The frame pointer is not usually necessary to the execution of code, so using it as a general purpose register will improve performance on register-starved architectures such as x86, but can interfere with debugging.

More recently frame-based stack unwinding is being replaced with unwind tables, but gdb still relies on the frame pointer if unwind tables are not present.