A backtrace is a summary of how your program got where it is. It shows one line per frame, for many frames, starting with the currently executing frame (frame zero), followed by its caller (frame one), and on up the stack.
You can stop the backtrace at any time by typing the system interrupt
character, normally Ctrl-c.
bt full -n
bt no-filters -n
bt no-filters full
bt no-filters fulln
bt no-filters full -n
info stack (abbreviated
are additional aliases for
In a multi-threaded program, gdb by default shows the
backtrace only for the current thread. To display the backtrace for
several or all of the threads, use the command
(see thread apply). For example, if you type thread
apply all backtrace, gdb will display the backtrace for all
the threads; this is handy when you debug a core dump of a
Each line in the backtrace shows the frame number and the function name.
The program counter value is also shown—unless you use
print address off. The backtrace also shows the source file name and
line number, as well as the arguments to the function. The program
counter value is omitted if it is at the beginning of the code for that
Here is an example of a backtrace. It was made with the command ‘bt 3’, so it shows the innermost three frames.
#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8) at builtin.c:993 #1 0x6e38 in expand_macro (sym=0x2b600, data=...) at macro.c:242 #2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08) at macro.c:71 (More stack frames follow...)
The display for frame zero does not begin with a program counter
value, indicating that your program has stopped at the beginning of the
code for line
The value of parameter
data in frame 1 has been replaced by
.... By default, gdb prints the value of a parameter
only if it is a scalar (integer, pointer, enumeration, etc). See command
set print frame-arguments in Print Settings for more details
on how to configure the way function parameter values are printed.
If your program was compiled with optimizations, some compilers will optimize away arguments passed to functions if those arguments are never used after the call. Such optimizations generate code that passes arguments through registers, but doesn't store those arguments in the stack frame. gdb has no way of displaying such arguments in stack frames other than the innermost one. Here's what such a backtrace might look like:
#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8) at builtin.c:993 #1 0x6e38 in expand_macro (sym=<optimized out>) at macro.c:242 #2 0x6840 in expand_token (obs=0x0, t=<optimized out>, td=0xf7fffb08) at macro.c:71 (More stack frames follow...)
The values of arguments that were not saved in their stack frames are shown as ‘<optimized out>’.
If you need to display the values of such optimized-out arguments, either deduce that from other variables whose values depend on the one you are interested in, or recompile without optimizations.
Most programs have a standard user entry point—a place where system
libraries and startup code transition into user code. For C this is
When gdb finds the entry function in a backtrace
it will terminate the backtrace, to avoid tracing into highly
system-specific (and generally uninteresting) code.
If you need to examine the startup code, or limit the number of levels in a backtrace, you can change this behavior:
set backtrace past-main
set backtrace past-main on
set backtrace past-main off
show backtrace past-main
set backtrace past-entry
set backtrace past-entry on
main(or equivalent) is called.
set backtrace past-entry off
show backtrace past-entry
set backtrace limitn
set backtrace limit 0
set backtrace limit unlimited
unlimitedor zero means unlimited levels.
show backtrace limit
You can control how file names are displayed.
set filename-display relative
set filename-display basename
set filename-display absolute
Note that embedded programs (the so-called “free-standing”
environment) are not required to have a
main function as the
entry point. They could even have multiple entry points.