3

I can't quite recall what library GCC works with to implement stack unwinding, which is used for c++ exceptions and call traces, and I know there's no means defined in the C++ specification, so any answers to this are platform specific. I am using GCC 4.9.0.

Knowing where something went wrong is very useful, especially during debugging. So quite often I'll have macros that expand and pass something __LINE__ and __FILE__ in the expansion.

I don't really like doing this, but it tells you where the function was called from (as the macros __LINE__ and __FILE__ are at the call site), which is really handy!

Rather than using some horrible macros being conditionally defined based on the build it'd be nice to have some conditionally defined code that uses the stack unwinding library.

What library is used? When one compiles can the compiler be told how much information to record? Obviously for a release build you just want what is needed for exception handling.

If not what is the convention? How do C++ programmers get what Python and Java programmers take for granted - verbose stack traces.

I suppose a fallback but not very elegant solution would be to create a new base from which I throw exceptions and have a macro that rethrows and appends line, file and __FUNCTION__, but this is a fallback.

I am interested in what library GCC uses and options to give to GCC to control how much info it puts in, so please share any knowledge you have on that!

Alec Teal
  • 5,770
  • 3
  • 23
  • 50
  • 3
    Use a debugger like GDB. When you get a core dump you'll get a nice stack trace, provided you compile with symbols (-g3 flag) – Charles Salvia Jan 15 '14 at 20:19
  • Is this about uncaught exceptions or crashes? – Sebastian Hoffmann Jan 15 '14 at 20:22
  • If I understand his question correctly, you want something like `__LINE__` but instead of the line the `__LINE__`, you want the line a function was called from? – olevegard Jan 15 '14 at 20:27
  • 1
    I don't use gcc much, but assuming you're using it on linux with libc, have you looked into backtrace() and friends? http://www.gnu.org/software/libc/manual/html_node/Backtraces.html – Aaron Jan 15 '14 at 20:27
  • you probably want to implement signal handler that calls backtrace, eg http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes – Anycorn Jan 15 '14 at 20:27
  • @CharlesSalvia nothing crashes and burns and I of course use a debugger, I fear giving an example incase everyne goes "DONT DO THAT2... say an assert fails in some highly reused code, you'd want to know where it calls from, but it may not be a fatal problem, you can return null but you want to report the garbage that came in - which is really only useful if you know where it came in from. Debuggers help but it can take forever, sometimes a program log helps and just let people use it. I usually have a logger that expects the file, and a macro that expands to pass where the log is appended. – Alec Teal Jan 15 '14 at 20:32
  • @AlecTeal that certainly make sense ("who was the jack-wagon that sent me this junk and caused my assertion failure?"). Failing loud is certainly an option (one I prefer), but you appear to want to log a backtrace, then continue with execution, perhaps returning an error-result to the caller etc. Is that about right? If so, and if you're on Linux, a `backtrace()` may be your ticket. – WhozCraig Jan 15 '14 at 20:41
  • @WhozCraig I'd really just like to avoid horrible macros for (certain) function calls and declarations, and definitions. It should not cause a fatal error if the user enters some crap that finds its way to something heavily reused that discards it. Inspecting the callstack here would be great because the log could note how it got that far, but anyway, yeah I'll look up backtrace, I expected GCC to be able to put a lot more data about the stack in with some compiler options, and that there'd be a library able to read it. – Alec Teal Jan 15 '14 at 20:49

1 Answers1

0

here is another option if you are using under linux.

1) design your signal handler, so any exception will be handled by your own signal handler instead of system like generating coredump file.

2) In your signal handler, using system call pstack to generate trace information as long as getting exception.

like ::system ("pstack yourpid >logfilename");

Arden
  • 21
  • 1