Notes on triggering stack traces in different languages, externally

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](https://docs.python.org/3/using/cmdline.html#envvar-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](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr016.html) 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.