Note:Most programming languages have some concept of functions, routines, or subroutines, capturing the notion of code that is invoked from many places. A running program needs a call stack of call frames for the called functions. Each call frame contains both the information needed to return to its caller and the information needed to contain the local variables of the function.
The machine code generated for these functions maintains this call stack. Some of this maintenance is done before the call, some at the start of the called function, some at the end of the called function, and some after the call.
Non-optimized machine code is usually very easy to correlate with the source code, but optimized machine code can be tricky. See Call Frames and Optimized Code and Call Frames and Machine Code Correlation for more information.
The debugger controls the call stacks of all the threads; you can use it to examine and manipulate call stacks, and use them as a basis for further queries:
call_stack_command
: show_stack_command
When your process is stopped by the debugger, you can show the call stack of the thread that caused the stoppage, or the call stack of any other thread.
The following commands show the most recent call frames on the call stack of the current or specified threads:
show_stack_command
: where [ expression ] [ thread_specifier ]
thread_specifier
: thread thread_id ,...
thread_id
show_stack_command
: Backtrace [ expression ]
| where [ expression ]
| info stack [ expression ]
| bt [ expression ]
If specified, the expression must evaluate to a non-negative integer. You can specify the number of call frames to show. If not specified, all the call frames for the thread are shown.
You can change the control variable $stack_levels to control number of call stack output levels. Default value is 50.
If specified, the thread_specifier specifies the threads whose call stacks are to be shown. If not specified, just the current thread is used.
When large and complex values are passed by value to a routine on the stack, the output of the where command can be voluminous. You can set the control variable $stackargs to 0 to suppress the output of argument values in the where command.
The stack trace provides the following information for each call level:
Call level |
The number used to refer to a call level on the stack. The function entered most recently is at level 0. Its caller is at level 1. |
|---|---|
| Memory address | The address of the next instruction to be executed at this level. |
| Function name | The name of the function for the memory address. |
| File name | The source file for the memory address. |
| Line number | The number of the next source line of the memory address. |
If your call stack seems to be missing routines, you may be seeing the result of a compiler optimization known as tail calls. When a function calls another function, typically it saves the return address, registers etc. on the stack before making a call, so that the callee can know where to return to once it is done. A new stack frame is also created for the callee. If the caller calls the callee as the last operation and just returns the result it got from callee, as is the case with some recursive functions, the compiler may convert the call to a branch or jump. This is called tail call optimization, and allows the callee to directly return results to the caller. In this case, the stack does not change and the caller function's stack frame is reused, which saves time and stack space. However, since no new frames are added, stack frames can be missing from the stack trace, which can ultimately adversely affect debugging.
If your call stack is corrupted, you may see random numbers without any routine names. In this case, it is likely that your application has gotten lost. Typically, this type of call stack display means that your application has lost track of the real stack and real code location, and is now executing random bits of memory, interpreting them as instructions.
If you are coding in C++, one of the most common ways to get a corrupt stack is for your code to try to execute a method on an invalid object. If the object has already been deleted, has not yet been initialized, is not there, or is of a completely different type, then the virtual function table will not be correct, and the application will be treating random memory as the virtual function table and calling a random place.
Note:You should change the current thread to the thread whose call stack you want to examine.
For unwinding live processes, the Linux version of IDB for ItaniumŪ-based systems uses the Hewlett-Packard libunwind* unwinder described at the following web site: http://www.hpl.hp.com/research/linux/libunwind/.
This unwinder supports programs that generate code at run-time and register that code along with rules describing how to unwind through it.
To unwind core files, a proprietary algorithm is used. It can also be used for live processes. In the unlikely event that the libunwind algorithm fails, you can force the following range of behaviors by setting either the debugger variable idb_libunwind_usage or the environment variable IDB_LIBUNWIND_USAGE to either 0, 1, 2, or 3: