Incomputing, astack trace (also calledstack backtrace[1] orstack traceback[2]) is a report of the activestack frames at a certain point in time during the execution of aprogram. When a program is run, memory is often dynamically allocated in two places: thestack and theheap. Memory is continuously allocated on a stack but not on a heap. Stack also refers to a programming construct, thus to differentiate it, this stack is referred to as the program'sfunction call stack. Technically, once a block of memory has been allocated on the stack, it cannot be easily removed as there can be other blocks of memory that were allocated after it. Each time a function is called in a program, a block of memory called anactivation record is allocated on top of the call stack. Generally, the activation record stores the function's arguments and local variables. What exactly it contains and how it's laid out is determined by thecalling convention.
Programmers commonly use stack tracing during interactive and post-mortemdebugging. End-users may see a stack trace displayed as part of anerror message, which the user can then report to a programmer.
A stack trace allows tracking the sequence ofnested functions called - up to the point where the stack trace is generated. In a post-mortem scenario this extends up to the function where the failure occurred (but was not necessarily caused).Sibling calls do not appear in a stack trace.
Many programming languages, includingJava[3] andC#,[4] have built-in support for retrieving the current stack trace via system calls. Beforestd::stacktrace was added in standard library as a container forstd::stacktrace_entry, pre-C++23 has no built-in support for doing this, but C++ users can retrieve stack traces with (for example) thestacktracelibrary. InJavaScript,exceptions hold astack property that contain the stack from the place where it was thrown.
As an example, the followingPython program contains an error.
defa()->int:i:int=0j:int=b(i)returnjdefb(z:int)->int:k:int=5ifz==0:c()returnk+zdefc()->None:error()if__name__=="__main__":a()
Running the program under the standard Python interpreter produces the following error message.
Traceback (most recent call last): File"file.py", line16, in<module>a() File"file.py", line3, inaj=b(i) File"file.py", line9, inbc() File"file.py", line13, incerror()NameError:name 'error' is not defined
The stack trace shows where the error occurs, namely in thec function. It also shows that thec function was called byb, which was called bya, which was in turn called by the code on line 16 (the last line) of the program. The activation records for each of these three functions would be arranged in a stack such that thea function would occupy the bottom of the stack and thec function would occupy the top of the stack.
InJava, stack traces can be dumped manually withThread.dumpStack()[5] Take the following input:
publicclassMain{staticvoiddemo(){demo1();}staticvoiddemo1(){demo2();}staticvoiddemo2(){demo3();}staticvoiddemo3(){Thread.dumpStack();}publicstaticvoidmain(Stringargs[]){demo();}}
The exception lists functions in descending order, so the most-inner call is first.
java.lang.Exception:Stacktraceatjava.lang.Thread.dumpStack(Thread.java:1336)atMain.demo3(Main.java:15)atMain.demo2(Main.java:11)atMain.demo1(Main.java:7)atMain.demo(Main.java:3)atMain.main(Main.java:19)
BothC andC++ (pre-C++23) do not have native support for obtaining stack traces, but libraries such asglibc andboost provide this functionality.[6][7] In these languages, some compiler optimizations may interfere with the call stack information that can be recovered at runtime. For instance,inlining can cause missing stack frames,tail call optimizations can replace one stack frame with another, and frame pointer elimination can prevent call stack analysis tools from correctly interpreting the contents of the call stack.[6]
For example, glibc'sbacktrace() function returns an output with the program function and memory address.
./a.out()[0x40067f]./a.out()[0x4006fe]./a.out()[0x40070a]/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f7e60738f45]./a.out()[0x400599]
As ofC++23, stack traces can be dumped manually by printing the value returned by static member functionstd::stacktrace::current():[8]
importstd;usingstd::stacktrace;voidbar(){std::println("Stacktrace from bar():\n{}",stacktrace::current());}voidfoo(){bar();}intmain(){foo();}
Rust has two types of errors. Functions that use the panicmacro are "unrecoverable" and the current thread will become poisoned experiencing stack unwinding. Functions that return astd::result::Result are "recoverable" and can be handled gracefully.[9] However, recoverable errors cannot generate a stack trace as they are manually added and not a result of a runtime error.
As of June 2021,Rust has experimental support for stack traces on unrecoverable errors. Rust supports printing tostderr when a thread panics, but it must be enabled by setting theRUST_BACKTRACEenvironment variable.[10]
When enabled, such backtraces look similar to below, with the most recent call first.
thread'main'panickedat'execute_to_panic',main.rs:3stackbacktrace:0:std::sys::imp::backtrace::tracing::imp::unwind_backtrace1:std::panicking::default_hook::{{closure}}2:std::panicking::default_hook3:std::panicking::rust_panic_with_hook4:std::panicking::begin_panic5:futures::task_impl::with6:futures::task_impl::park...