Notes on triggering stack traces in different languages, externally

[rrnewton]

From the perspective of a native-code debugger, interpreting runtime states to extract a stack trace for arbitrary languages (interpreted, JIT-compiled, AOT-compiled...) is a hard problem. There are some attempts to teach debuggers how to access this runtime state, like py-bt via GDB Python extensions. But ultimately a language's interpreter/compiler/runtime is the source of truth for how to read that language's stack frames.

Fortunately, many languages an external trigger, typically a signal (e.g. SIGTRAP) can trigger the runtime to print its stacktrace from a signal handler. Therefore, especially if you are willing to throw away the current process (or have a fork/backup it), you can get out a language-specific stack trace. This issue is a place to accumulate notes on doing that, per-language.

Python

Setting the PYTHONFAULTHANDLER environment variable to 1 will put the runtime in a state where certain signals, including SIGABRT, will cause it to dump a traceback.

Java

The jcmd / jstack utilities provide a way to signal the JVM runtime to dump the current stacktraces to wherever its logging stdout is currently going.

.NET (CLR, mono)

Rust, C, C++

In these native languages, gdb or lldb can read the backtrace, or libunwind can be used to do it.