Add architecture-specific capture of call stack at time of construction of cet::exception.
#3 Updated by Christopher Backhouse about 6 years ago
I imagine we'd be interested in this. Maybe it could be brought up at a meeting?
The current flow is:
1. Run job
3. Job throws exception
4. Restart job inside debugger
5. Enter incantation to get debugger to break on exceptions
7. See stack trace of exception (and possibly inspect variable values)
Normally the stacktrace is enough to understand what happened, and having it in the output would eliminate steps 4-7 in the common case.
#5 Updated by Christopher Green over 4 years ago
- Estimated time changed from 80.00 h to 16.00 h
- SSI Package cetlib added
A quick search online reveals: https://panthema.net/2008/0901-stacktrace-demangled/, which describes using the libc functions
backtrace_symbols(3) along with the
cxxabi demangling facilities to produce a usable backtrace in most circumstances. Note that a stack frame and frame pointer are required in order for code to have a useful entry in this backtrace (ruling out inlined functions and
-O3 optimized code where
-fno-omit-frame-pointer is not used), and the code must be compiled with
-rdynamic, ruling out statically-linked code. Assuming simple tests prove that this is useful for our code, this should be relatively simple to implement.