[PROPOSAL] Backtrace

[ray6080]

The goal is to provide more debugging info when Kuzu throws exceptions, errors or segfaults.

Backtrace can provide a list of the function calls that are currently active in a thread. Usually we need to use an external debugger such as gdb/lldb to get this kind of information.
However, under some cases, using an external debugger is not trivial. for example, when user reports seg faults, we have to reproduce with a user-provided minimal example; sometimes a bug cannot be stably reproduced locally but on CI pipelines, which makes it harder to debug. In these cases, printing stack traces can be helpful.

Expected behaviour is when DEBUG_STACKTRACE is enabled:

1. Print stack traces when Kuzu throws kuAssertFailureInternal exceptions.
2. Use signal handling to catch seg faults and print stack traces.

We can start with Linux and MacOS platforms.
GlibC provides a set of functions for backtracing. https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
Also see here for signal handling. https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-stacktrace-when-my-program-crashes

This is an initial draft, more comments are welcome :)

[prrao87]

Would love to learn more and communicate more with the community on how we can help debug errors and segfaults better, so will be following this one closely 😄.

[benjaminwinger]

cpptrace might be a useful library for handling traces. Using glibc bactrace functions by themselves the function symbols weren't being displayed correctly, but with cpptrace and debug symbols it worked. It also works on macos and Windows. We would need to switch to using RelWithDebInfo for CI jobs if we want to get helpful backtraces.

It looks like backtraces for exceptions are significantly simpler than backtraces for signals though. See https://github.com/jeremy-rifkin/cpptrace/blob/main/docs/signal-safe-tracing.md, but in short, anything signal handler have specific safety requirements (more details here), since you can trigger the signal handler within the signal handler (usually resolving signals is handled by a separate forked process for this reason, which would be fine in CI, but more difficult in production unless we were to just dump the data to a file that could be provided along with error reports).