2605:8D80:6C24:88A9:E0B2:AD7C:76A8:4BDF: /* Java */

2025-10-19T15:53:24Z

Java

New page

{{Short description|Report of stack frames during program execution}}
{{Redirect|Backtrace|the 2018 film|Backtrace (film)}}

In [[computing]], a '''stack trace''' (also called '''stack backtrace'''<ref>{{cite web | url=https://www.gnu.org/software/libc/manual/html_node/Backtraces.html | title=libc manual: backtraces | publisher=gnu.org | accessdate=8 July 2014}}</ref> or '''stack traceback'''<ref>{{cite web | url=https://docs.python.org/3/library/traceback.html | title=traceback — Print or retrieve a stack traceback | publisher=python.org | accessdate=8 July 2014}}</ref>) is a report of the active [[stack frame]]s at a certain point in time during the execution of a [[computer program|program]]. When a program is run, memory is often dynamically allocated in two places: the [[Stack (abstract data type)#Hardware stack|stack]] and the [[Memory_management#HEAP|heap]]. 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's '''[[Call stack|function 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 an '''activation 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 the [[calling convention]].

Programmers commonly use stack tracing during interactive and post-mortem [[debugging]]. End-users may see a stack trace displayed as part of an [[error message]], which the user can then report to a programmer.

A stack trace allows tracking the sequence of [[nested function]]s 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). [[Tail call|Sibling calls]] do not appear in a stack trace.

== Language support ==
Many programming languages, including [[Java (programming language)|Java]]<ref>{{cite web | title=Thread (Java SE 16 & JDK 16) | website=Java Platform Standard Edition & Java Development Kit Version 16 API Specification | date=2021-03-04 | url=https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Thread.html#getStackTrace() | access-date=2021-07-04}}</ref> and [[C Sharp (programming language)|C#]],<ref>{{cite web | title=Environment.StackTrace Property (System) | website=Microsoft Docs | date=2021-05-07 | url=https://docs.microsoft.com/en-us/dotnet/api/system.environment.stacktrace | access-date=2021-07-04}}</ref> have built-in support for retrieving the current stack trace via system calls. Before <code>std::stacktrace</code> was added in standard library as a container for <code>std::stacktrace_entry</code>, pre-[[C++23]] has no built-in support for doing this, but C++ users can retrieve stack traces with (for example) the [https://stacktrace.sourceforge.net/ stacktrace] [[library (computing)|library]]. In [[JavaScript]], [[Exception handling|exceptions]] hold a <code>stack</code> property that contain the stack from the place where it was thrown.

=== Python ===
As an example, the following [[Python (programming language)|Python]] program contains an error.
<syntaxhighlight lang="python" line="1" highlight="3,9,13,16">
def a() -> int:
i: int = 0
j: int = b(i)
return j

def b(z: int) -> int:
k: int = 5
if z == 0:
c()
return k + z

def c() -> None:
error()

if __name__ == "__main__":
a()
</syntaxhighlight>
Running the program under the standard Python interpreter produces the following error message.
<syntaxhighlight lang="pytb">
Traceback (most recent call last):
File "file.py", line 16, in <module>
a()
File "file.py", line 3, in a
j = b(i)
File "file.py", line 9, in b
c()
File "file.py", line 13, in c
error()
NameError: name 'error' is not defined
</syntaxhighlight>
The stack trace shows where the error occurs, namely in the <code>c</code> function. It also shows that the <code>c</code> function was called by <code>b</code>, which was called by <code>a</code>, which was in turn called by the code on line 15 (the last line) of the program. The activation records for each of these three functions would be arranged in a stack such that the <code>a</code> function would occupy the bottom of the stack and the <code>c</code> function would occupy the top of the stack.

=== Java ===
In [[Java (programming language)|Java]], stack traces can be dumped manually with <code>Thread.dumpStack()</code><ref>{{Cite web|title=Thread (Java Platform SE 8 )|url=https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#dumpStack--|access-date=2021-06-15|website=docs.oracle.com}}</ref> Take the following input:
<syntaxhighlight lang="java" line="1" highlight="3,7,11,19">
public class Main {
static void demo() {
demo1();
}

static void demo1() {
demo2();
}

static void demo2() {
demo3();
}

static void demo3() {
Thread.dumpStack();
}

public static void main(String args[]) {
demo();
}
}
</syntaxhighlight>

The exception lists functions in descending order, so the most-inner call is first.

<syntaxhighlight lang="java">
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1336)
at Main.demo3(Main.java:15)
at Main.demo2(Main.java:11)
at Main.demo1(Main.java:7)
at Main.demo(Main.java:3)
at Main.main(Main.java:19)
</syntaxhighlight>

=== C and C++ ===
Both [[C (programming language)|C]] and [[C++]] (pre-[[C++23]]) do not have native support for obtaining stack traces, but libraries such as [[GNU C Library|glibc]] and [[Boost (C++ libraries)|boost]] provide this functionality.<ref name="glibc Backtraces">{{Cite web|title=Backtraces (The GNU C Library)|url=https://www.gnu.org/software/libc/manual/html_node/Backtraces.html|access-date=2021-06-15|website=www.gnu.org}}</ref><ref>{{Cite web|title=Getting Started - 1.76.0|url=https://www.boost.org/doc/libs/1_76_0/doc/html/stacktrace/getting_started.html|access-date=2021-06-15|website=www.boost.org}}</ref> In these languages, some compiler optimizations may interfere with the call stack information that can be recovered at runtime. For instance, [[Inline expansion|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.<ref name="glibc Backtraces" />

For example, glibc's <code>backtrace()</code> function returns an output with the program function and memory address.
<syntaxhighlight lang="c">
./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]
</syntaxhighlight>

As of [[C++23]], stack traces can be dumped manually by printing the value returned by static member function <code>std::stacktrace::current()</code>:<ref>{{Cite web|date=2021-10-23|title=Working Draft, Standard for Programming Language C++|url=http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/n4901.pdf|website=open-std.org|publisher=ISO/IEC|page=766}}</ref>
<syntaxhighlight lang="c++">
import std;

using std::stacktrace;

void bar() {
std::println("Stacktrace from bar():\n{}", stacktrace::current());
}

void foo() {
bar();
}

int main() {
foo();
}
</syntaxhighlight>

=== Rust ===
[[Rust (programming language)|Rust]] has two types of errors. Functions that use the panic [[Macro (computer science)|macro]] are "unrecoverable" and the current thread will become poisoned experiencing stack unwinding. Functions that return a <code>std::result::Result</code> are "recoverable" and can be handled gracefully.<ref>{{Cite web|title=rustonomicon unwinding - Rust|url=https://doc.rust-lang.org/nomicon/unwinding.html#:~:text=Rust%20has%20a%20tiered%20error,be%20handled%2C%20the%20thread%20panics.|website=doc.rust-lang.org}}</ref> 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 (programming language)|Rust]] has experimental support for stack traces on unrecoverable errors. Rust supports printing to [[stderr]] when a thread panics, but it must be enabled by setting the <code>RUST_BACKTRACE</code> [[environment variable]].<ref>{{Cite web|title=std::backtrace - Rust|url=https://doc.rust-lang.org/std/backtrace/index.html|access-date=2021-06-15|website=doc.rust-lang.org}}</ref>

When enabled, such backtraces look similar to below, with the most recent call first.
<syntaxhighlight lang="rust">
thread 'main' panicked at 'execute_to_panic', main.rs:3
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
1: std::panicking::default_hook::{{closure}}
2: std::panicking::default_hook
3: std::panicking::rust_panic_with_hook
4: std::panicking::begin_panic
5: futures::task_impl::with
6: futures::task_impl::park
...
</syntaxhighlight>

==See also==
* [[Tail call]]
* [[Context (computing)]]
* [[Stack overflow]]
* [[Exception handling]]
* [[Call stack]]

==References==
{{reflist}}

{{DEFAULTSORT:Stack Trace}}
[[Category:Debugging]]
[[Category:Articles with example Python (programming language) code]]

Stack trace - Revision history

2605:8D80:6C24:88A9:E0B2:AD7C:76A8:4BDF: /* Java */