Python Traceback Analyzer

About Stack Trace Analyzer

A stack trace, crash or thread dump pasted in, broken into the parts you actually read: what was thrown, the chain of causes beneath it, every frame in order, and whether each frame is your own code, a library, or the language's runtime.

The language is recognised by shape, or can be chosen when a short trace is ambiguous: Java, Kotlin, Scala and Clojure; Python; Go; Rust; C# and .NET; JavaScript and TypeScript; PHP; Ruby; C and C++; Swift and Objective-C crash reports; Dart and Flutter; Elixir and Erlang; Lua; Perl; Haskell; Julia; and OCaml.

Each is read in the forms it actually arrives in. Python: chained tracebacks, exception groups and pytest failures. Go: panics with every goroutine, created by lines and deadlocks, with the standard library told apart from modules in pkg/mod. Java: Caused by and Suppressed, logback's omitted frames, Android logcat, and jstack thread dumps with each thread's state, its locks and any deadlock. Rust: default and full backtraces, and anyhow cause chains. .NET: ---> inner exceptions, with async and lambda names made readable. PHP: plain, Laravel-logged and Xdebug traces. C and C++: gdb, LLDB, AddressSanitizer, UBSan, Valgrind and glibc backtraces.

Timestamps, log levels, docker compose container names and logcat prefixes are taken off each line first, so a trace copied straight out of a log viewer reads the same as a clean one.

The single most useful line is *start reading at*: the first frame of your own code, taken from the root cause where it has one. For the common errors — a nil map in Go, 'NoneType' object is not subscriptable, Sequence contains no elements, a heap-use-after-free — the analyzer also says what the error usually means and what to check first. Repeating frames are collapsed into a single recursion line. Naming your own package or path — com.example, /app/src — settles which frames are yours outright.

It runs here in the browser, which matters — a stack trace from production carries file paths, class names and sometimes data.

Where it helps

• Recognises twenty runtimes by shape, including thread dumps, test-runner output and native debugger backtraces, with a manual override.
• Follows the chain of causes to the root whichever order the runtime prints it in, and keeps suppressed, grouped and bystander-thread exceptions out of that chain.
• Separates your code, libraries and the runtime, and points at the first frame worth opening.
• Explains the common errors of each language and says what to check first.
• Strips log timestamps and container prefixes, and spots recursion and deadlocks.
• Counts where the frames come from, so a trace dominated by one dependency shows it.
• Runs locally, so a production trace stays on your machine.

Limits

• Without a package or path of your own given, whether a frame is yours is judged by well-known patterns, and an unusual layout may be labelled wrongly.
• Minified JavaScript frames are read as they are — apply a source map first if you want real names.
• Symbolicated names are shown as printed: Swift and C++ symbols are not demangled, and unsymbolicated addresses stay addresses.
• The explanations are the usual cause of an error, not a diagnosis of this one — the trace alone cannot say why the value was null.

Frequently asked questions

Which languages does it understand?

Java, Kotlin, Scala and Clojure; Python, including pytest output; Go; Rust; C# and .NET, including Unity; JavaScript and TypeScript from Chrome, Node, Firefox and Safari; PHP; Ruby; C and C++ from gdb, LLDB, the sanitizers, Valgrind and glibc; Swift and Objective-C crash reports; Dart and Flutter; Elixir; Erlang; Lua; Perl; Haskell; Julia; and OCaml. Anything else is read with the JavaScript rules and may lose some detail — choosing the closest language usually does better.

What does 'start reading at' mean?

It is the first frame that is not in a dependency or a runtime — the earliest point where the failure passes through code you can change. It is usually the right line to open first.

Why does the root cause differ from the exception at the top?

Because the top exception is often a wrapper. Each Caused by: unwraps one layer, and the last one is what actually went wrong — a timeout, a null, a refused connection.

What does '... 12 more' mean in a Java trace?

The runtime elided frames identical to the trace above it. They are the same frames, not missing ones, and the count is reported as it was written.

Related tools

• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing
• Regex Tester — Test patterns, inspect groups and preview replacements
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• IDN Homograph Detector — Check whether a domain name is imitating another one
• Phishing URL Checker — Where a link really ends up, how old the domain is, and which tricks it uses

More Analyzers tools

• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing
• IDN Homograph Detector — Check whether a domain name is imitating another one
• Phishing URL Checker — Where a link really ends up, how old the domain is, and which tricks it uses
• Injection Filter Tester — Standard probes per context, and whether your escaping survived them
• Stack Trace Analyzer — Read a stack trace or crash in any common language: the cause, your frames, and what it usually means