Getting a stack trace without throwing an exception

When debugging, it may be helpful to get a stack trace without changing the flow of execution. Throwing an exception will get you a stack trace, but it will also terminate the program. How can we extract the stack trace without actually unwinding the call stack?

How to do it…

To get a stack trace without throwing an exception, we need to execute the following steps:

1. Import core.runtime;.

2. Call defaultTraceHandler() to get an instance of Throwable.TraceInfo.

3. On Posix systems, wrap the call to defaultTraceHandler in four functions to ensure relevant data is not cut out by druntime.

4. Return or print trace.toString().

The code is as follows:

string getStackTrace() {
  import core.runtime;

  version(Posix) {
    // druntime cuts out the first few functions on the trace because they are internal
    // so we'll make some dummy functions here so our actual info doesn't get cut
    Throwable.TraceInfo f4() { return defaultTraceHandler(); }
    Throwable.TraceInfo f3() { return f4(); }
    Throwable.TraceInfo f2() { return f3(); }
    Throwable.TraceInfo f1() { return f2(); }
    auto strace = f1();
  } else {
    auto trace = defaultTraceHandler();
  }

  return trace.toString();
}

We can test the function by calling it inside another program. The value this function returns matches the stack trace seen when an exception is printed.

Tip

You may have to compile with debug information turned on (dmd –g –debug) to get file and line information about your call stack.

How it works…

When an exception is thrown in D, the trace handler is called to gather information about the call stack. When the exception is printed with toString, it also calls trace.toString to add the stack trace to the message.

The trace handler is also available outside of exceptions by importing core.runtime. It works the same way and provides the same string without modifying the program's execution state. The only tricky part is on Posix. The trace handler ignores the first several lines of the result because they are typically functions internal to druntime. Since we're using the handler outside of the druntime context, this behavior would cut off relevant information!

As a work around, we wrap the call to defaultTraceHandler in several dummy functions so they are removed by the handler's truncation instead of information we actually care about.

Note

Generating the stack trace string is an expensive operation, so only use it as a debugging tool. A full stack trace used to be immediately generated any time an exception was thrown. This proved to be an enormous performance problem, so the code was changed. Now, a snapshot of the stack trace is taken immediately, but resolving it into a string with function names is done lazily upon a call to toString. The result is about a 1000 times speedup of exceptions thrown and caught inside the application.