Project

General

Profile

Idea #918

Add architecture-specific capture of call stack at time of construction of cet::exception.

Added by Christopher Green almost 9 years ago. Updated about 2 years ago.

Status:
Accepted
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
16.00 h
Experiment:
-
SSI Package:
cetlib
Duration:

Related issues

Related to cetlib_except - Feature #14795: Traceback printout on fatal exceptions would be niceAccepted12/09/2016

Has duplicate cet-is - Feature #8171: Improve the messages for cet::exceptionAccepted03/25/2015

History

#1 Updated by Walter E Brown almost 8 years ago

  • Status changed from New to Accepted

#2 Updated by Christopher Green over 6 years ago

  • Tracker changed from Feature to Idea
  • Start date deleted (02/01/2011)
  • Estimated time set to 80.00 h
  • Experiment - added

Demoted to "idea" until there is significant experimental interest.

#3 Updated by Christopher Backhouse over 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
2. Wait
3. Job throws exception
4. Restart job inside debugger
5. Enter incantation to get debugger to break on exceptions
6. Wait
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.

#4 Updated by Christopher Green over 4 years ago

  • Has duplicate Feature #8171: Improve the messages for cet::exception added

#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(3) and 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.

#6 Updated by Kyle Knoepfel over 4 years ago

  • Target version set to 521

#7 Updated by Kyle Knoepfel almost 3 years ago

  • Related to Feature #14795: Traceback printout on fatal exceptions would be nice added

#8 Updated by Kyle Knoepfel about 2 years ago

  • Target version deleted (521)

Also available in: Atom PDF