Hermit launches linux x86_64 programs in a special, hermetically isolated sandbox to control their execution. Hermit translates normal, nondeterministic behavior, into deterministic, repeatable behavior. This can be used for various applications, including replay-debugging, reproducible artifacts, chaos mode concurrency testing and bug analysis.
Other
1.17k
stars
31
forks
source link
Notes on triggering stack traces in different languages, externally #8
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.
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-btvia 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.