By KPexEA


2008-09-16 20:58:35 8 Comments

I am working on Linux with the GCC compiler. When my C++ program crashes I would like it to automatically generate a stacktrace.

My program is being run by many different users and it also runs on Linux, Windows and Macintosh (all versions are compiled using gcc).

I would like my program to be able to generate a stack trace when it crashes and the next time the user runs it, it will ask them if it is ok to send the stack trace to me so I can track down the problem. I can handle the sending the info to me but I don't know how to generate the trace string. Any ideas?

28 comments

@Geoffrey 2019-04-11 06:45:28

If you still want to go it alone as I did you can link against bfd and avoid using addr2line as I have done here:

https://github.com/gnif/LookingGlass/blob/master/common/src/crash.linux.c

This produces the output:

[E]        crash.linux.c:170  | crit_err_hdlr                  | ==== FATAL CRASH (a12-151-g28b12c85f4+1) ====
[E]        crash.linux.c:171  | crit_err_hdlr                  | signal 11 (Segmentation fault), address is (nil)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (0) /home/geoff/Projects/LookingGlass/client/src/main.c:936 (register_key_binds)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (1) /home/geoff/Projects/LookingGlass/client/src/main.c:1069 (run)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (2) /home/geoff/Projects/LookingGlass/client/src/main.c:1314 (main)
[E]        crash.linux.c:199  | crit_err_hdlr                  | [trace]: (3) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f8aa65f809b]
[E]        crash.linux.c:199  | crit_err_hdlr                  | [trace]: (4) ./looking-glass-client(_start+0x2a) [0x55c70fc4aeca]

@baziorek 2019-01-29 18:55:42

It looks like in one of last c++ boost version appeared library to provide exactly what You want, probably the code would be multiplatform. It is boost::stacktrace, which You can use like as in boost sample:

#include <filesystem>
#include <sstream>
#include <fstream>
#include <signal.h>     // ::signal, ::raise
#include <boost/stacktrace.hpp>

const char* backtraceFileName = "./backtraceFile.dump";

void signalHandler(int)
{
    ::signal(SIGSEGV, SIG_DFL);
    ::signal(SIGABRT, SIG_DFL);
    boost::stacktrace::safe_dump_to(backtraceFileName);
    ::raise(SIGABRT);
}

void sendReport()
{
    if (std::filesystem::exists(backtraceFileName))
    {
        std::ifstream file(backtraceFileName);

        auto st = boost::stacktrace::stacktrace::from_dump(file);
        std::ostringstream backtraceStream;
        backtraceStream << st << std::endl;

        // sending the code from st

        file.close();
        std::filesystem::remove(backtraceFileName);
    }
}

int main()
{
    ::signal(SIGSEGV, signalHandler);
    ::signal(SIGABRT, signalHandler);

    sendReport();
    // ... rest of code
}

In Linux You compile the code above:

g++ --std=c++17 file.cpp -lstdc++fs -lboost_stacktrace_backtrace -ldl -lbacktrace

Example backtrace copied from boost documentation:

0# bar(int) at /path/to/source/file.cpp:70
1# bar(int) at /path/to/source/file.cpp:70
2# bar(int) at /path/to/source/file.cpp:70
3# bar(int) at /path/to/source/file.cpp:70
4# main at /path/to/main.cpp:93
5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
6# _start

@IInspectable 2018-03-01 13:00:47

As a Windows-only solution, you can get the equivalent of a stack trace (with much, much more information) using Windows Error Reporting. With just a few registry entries, it can be set up to collect user-mode dumps:

Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. [...]

This feature is not enabled by default. Enabling the feature requires administrator privileges. To enable and configure the feature, use the following registry values under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key.

You can set the registry entries from your installer, which has the required privileges.

Creating a user-mode dump has the following advantages over generating a stack trace on the client:

  • It's already implemented in the system. You can either use WER as outlined above, or call MiniDumpWriteDump yourself, if you need more fine-grained control over the amount of information to dump. (Make sure to call it from a different process.)
  • Way more complete than a stack trace. Among others it can contain local variables, function arguments, stacks for other threads, loaded modules, and so on. The amount of data (and consequently size) is highly customizable.
  • No need to ship debug symbols. This both drastically decreases the size of your deployment, as well as makes it harder to reverse-engineer your application.
  • Largely independent of the compiler you use. Using WER does not even require any code. Either way, having a way to get a symbol database (PDB) is very useful for offline analysis. I believe GCC can either generate PDB's, or there are tools to convert the symbol database to the PDB format.

Take note, that WER can only be triggered by an application crash (i.e. the system terminating a process due to an unhandled exception). MiniDumpWriteDump can be called at any time. This may be helpful if you need to dump the current state to diagnose issues other than a crash.

Mandatory reading, if you want to evaluate the applicability of mini dumps:

@Roy 2016-12-31 00:19:02

The new king in town has arrived https://github.com/bombela/backward-cpp

1 header to place in your code and 1 library to install.

Personally I call it using this function

#include "backward.hpp"
void stacker() {

using namespace backward;
StackTrace st;


st.load_here(99); //Limit the number of trace depth to 99
st.skip_n_firsts(3);//This will skip some backward internal function from the trace

Printer p;
p.snippet = true;
p.object = true;
p.color = true;
p.address = true;
p.print(st, stderr);
}

@tglas 2019-12-01 20:09:17

Wow! That's finally how it should be done! I have just dumped by own solution in favor of this one.

@Simon Steele 2008-09-17 11:31:00

Might be worth looking at Google Breakpad, a cross-platform crash dump generator and tools to process the dumps.

@DBedrenko 2016-08-02 11:15:41

It reports on stuff like segmentation faults, but it doesn't report any info on unhandled C++ exceptions.

@loopzilla 2016-07-06 12:37:15

Forget about changing your sources and do some hacks with backtrace() function or macroses - these are just poor solutions.

As a properly working solution, I would advice:

  1. Compile your program with "-g" flag for embedding debug symbols to binary (don't worry this will not impact your performance).
  2. On linux run next command: "ulimit -c unlimited" - to allow system make big crash dumps.
  3. When your program crashed, in the working directory you will see file "core".
  4. Run next command to print backtrace to stdout: gdb -batch -ex "backtrace" ./your_program_exe ./core

This will print proper readable backtrace of your program in human readable way (with source file names and line numbers). Moreover this approach will give you freedom to automatize your system: have a short script that checks if process created a core dump, and then send backtraces by email to developers, or log this into some logging system.

@HeyJude 2019-05-10 14:17:26

It gives the wrong line numbers. Can it be improved?

@jhclark 2011-07-06 15:51:26

It's even easier than "man backtrace", there's a little-documented library (GNU specific) distributed with glibc as libSegFault.so, which was I believe was written by Ulrich Drepper to support the program catchsegv (see "man catchsegv").

This gives us 3 possibilities. Instead of running "program -o hai":

  1. Run within catchsegv:

    $ catchsegv program -o hai
    
  2. Link with libSegFault at runtime:

    $ LD_PRELOAD=/lib/libSegFault.so program -o hai
    
  3. Link with libSegFault at compile time:

    $ gcc -g1 -lSegFault -o program program.cc
    $ program -o hai
    

In all 3 cases, you will get clearer backtraces with less optimization (gcc -O0 or -O1) and debugging symbols (gcc -g). Otherwise, you may just end up with a pile of memory addresses.

You can also catch more signals for stack traces with something like:

$ export SEGFAULT_SIGNALS="all"       # "all" signals
$ export SEGFAULT_SIGNALS="bus abrt"  # SIGBUS and SIGABRT

The output will look something like this (notice the backtrace at the bottom):

*** Segmentation fault Register dump:

 EAX: 0000000c   EBX: 00000080   ECX:
00000000   EDX: 0000000c  ESI:
bfdbf080   EDI: 080497e0   EBP:
bfdbee38   ESP: bfdbee20

 EIP: 0805640f   EFLAGS: 00010282

 CS: 0073   DS: 007b   ES: 007b   FS:
0000   GS: 0033   SS: 007b

 Trap: 0000000e   Error: 00000004  
OldMask: 00000000  ESP/signal:
bfdbee20   CR2: 00000024

 FPUCW: ffff037f   FPUSW: ffff0000  
TAG: ffffffff  IPOFF: 00000000  
CSSEL: 0000   DATAOFF: 00000000  
DATASEL: 0000

 ST(0) 0000 0000000000000000   ST(1)
0000 0000000000000000  ST(2) 0000
0000000000000000   ST(3) 0000
0000000000000000  ST(4) 0000
0000000000000000   ST(5) 0000
0000000000000000  ST(6) 0000
0000000000000000   ST(7) 0000
0000000000000000

Backtrace:
/lib/libSegFault.so[0xb7f9e100]
??:0(??)[0xb7fa3400]
/usr/include/c++/4.3/bits/stl_queue.h:226(_ZNSt5queueISsSt5dequeISsSaISsEEE4pushERKSs)[0x805647a]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/player.cpp:73(_ZN6Player5inputESs)[0x805377c]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:159(_ZN6Socket4ReadEv)[0x8050698]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:413(_ZN12ServerSocket4ReadEv)[0x80507ad]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:300(_ZN12ServerSocket4pollEv)[0x8050b44]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/main.cpp:34(main)[0x8049a72]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d1b775]
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8049801]

If you want to know the gory details, the best source is unfortunately the source: See http://sourceware.org/git/?p=glibc.git;a=blob;f=debug/segfault.c and its parent directory http://sourceware.org/git/?p=glibc.git;a=tree;f=debug

@HHK 2013-01-23 18:05:04

"Possibility 3. Link with libSegFault at compile time" does not work.

@Stéphane Gourichon 2014-03-31 09:33:36

@crafter: What do you mean "does not work". What have you tried, on what language/compiler/toolchain/distribution/hardware ? Did it fail to compile ? To catch error ? To produce output at all ? To produce hard-to-use output ? Thank you for details it will help everyone.

@greggo 2014-07-03 16:06:05

'best source is unfortunately the source' ... Hopefully, some day, the man page for catchsegv will actually mention SEGFAULT_SIGNALS. Until then, there's this answer to refer to.

@DavidMFrey 2016-03-16 12:44:02

I can't believe I've been programming C for 5 years and never heard of this :/

@Phillip 2016-07-28 08:49:04

@StéphaneGourichon @HansKratz To link with libSegFault you'll have to add -Wl,--no-as-needed to the compiler flags. Otherwise, ld will indeed not link against libSegFault, because it recognizes that the binary doesn't use any of its symbols.

@Joseph 2008-09-16 21:23:20

ulimit -c <value> sets the core file size limit on unix. By default, the core file size limit is 0. You can see your ulimit values with ulimit -a.

also, if you run your program from within gdb, it will halt your program on "segmentation violations" (SIGSEGV, generally when you accessed a piece of memory that you hadn't allocated) or you can set breakpoints.

ddd and nemiver are front-ends for gdb which make working with it much easier for the novice.

@Adam Hawes 2009-02-04 13:07:18

Core dumps are infinitely more useful than stack traces because you can load the core dump in the debugger and see the state of the whole program and its data at the point of the crash.

@nobar 2010-10-26 13:36:07

The backtrace facility that others have suggested is probably better than nothing, but it is very basic -- it doesn't even give line numbers. Using core dumps, on the other hand, let's you retroactively view the entire state of your application at the time it crashed (including a detailed stack trace). There might be practical issues with trying to use this for field debugging, but it is definitely a more powerful tool for analyzing crashes and asserts during development (at least on Linux).

@Brian Mitchell 2008-09-16 20:52:39

You did not specify your operating system, so this is difficult to answer. If you are using a system based on gnu libc, you might be able to use the libc function backtrace().

GCC also has two builtins that can assist you, but which may or may not be implemented fully on your architecture, and those are __builtin_frame_address and __builtin_return_address. Both of which want an immediate integer level (by immediate, I mean it can't be a variable). If __builtin_frame_address for a given level is non-zero, it should be safe to grab the return address of the same level.

@Daneel S. Yaitskov 2014-03-20 11:59:22

I found that @tgamblin solution is not complete. It cannot handle with stackoverflow. I think because by default signal handler is called with the same stack and SIGSEGV is thrown twice. To protect you need register an independent stack for the signal handler.

You can check this with code below. By default the handler fails. With defined macro STACK_OVERFLOW it's all right.

#include <iostream>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#include <string>
#include <cassert>

using namespace std;

//#define STACK_OVERFLOW

#ifdef STACK_OVERFLOW
static char stack_body[64*1024];
static stack_t sigseg_stack;
#endif

static struct sigaction sigseg_handler;

void handler(int sig) {
  cerr << "sig seg fault handler" << endl;
  const int asize = 10;
  void *array[asize];
  size_t size;

  // get void*'s for all entries on the stack
  size = backtrace(array, asize);

  // print out all the frames to stderr
  cerr << "stack trace: " << endl;
  backtrace_symbols_fd(array, size, STDERR_FILENO);
  cerr << "resend SIGSEGV to get core dump" << endl;
  signal(sig, SIG_DFL);
  kill(getpid(), sig);
}

void foo() {
  foo();
}

int main(int argc, char **argv) {
#ifdef STACK_OVERFLOW
  sigseg_stack.ss_sp = stack_body;
  sigseg_stack.ss_flags = SS_ONSTACK;
  sigseg_stack.ss_size = sizeof(stack_body);
  assert(!sigaltstack(&sigseg_stack, nullptr));
  sigseg_handler.sa_flags = SA_ONSTACK;
#else
  sigseg_handler.sa_flags = SA_RESTART;  
#endif
  sigseg_handler.sa_handler = &handler;
  assert(!sigaction(SIGSEGV, &sigseg_handler, nullptr));
  cout << "sig action set" << endl;
  foo();
  return 0;
} 

@Todd Gamblin 2008-09-16 21:30:26

For Linux and I believe Mac OS X, if you're using gcc, or any compiler that uses glibc, you can use the backtrace() functions in execinfo.h to print a stacktrace and exit gracefully when you get a segmentation fault. Documentation can be found in the libc manual.

Here's an example program that installs a SIGSEGV handler and prints a stacktrace to stderr when it segfaults. The baz() function here causes the segfault that triggers the handler:

#include <stdio.h>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>


void handler(int sig) {
  void *array[10];
  size_t size;

  // get void*'s for all entries on the stack
  size = backtrace(array, 10);

  // print out all the frames to stderr
  fprintf(stderr, "Error: signal %d:\n", sig);
  backtrace_symbols_fd(array, size, STDERR_FILENO);
  exit(1);
}

void baz() {
 int *foo = (int*)-1; // make a bad pointer
  printf("%d\n", *foo);       // causes segfault
}

void bar() { baz(); }
void foo() { bar(); }


int main(int argc, char **argv) {
  signal(SIGSEGV, handler);   // install our handler
  foo(); // this will call foo, bar, and baz.  baz segfaults.
}

Compiling with -g -rdynamic gets you symbol info in your output, which glibc can use to make a nice stacktrace:

$ gcc -g -rdynamic ./test.c -o test

Executing this gets you this output:

$ ./test
Error: signal 11:
./test(handler+0x19)[0x400911]
/lib64/tls/libc.so.6[0x3a9b92e380]
./test(baz+0x14)[0x400962]
./test(bar+0xe)[0x400983]
./test(foo+0xe)[0x400993]
./test(main+0x28)[0x4009bd]
/lib64/tls/libc.so.6(__libc_start_main+0xdb)[0x3a9b91c4bb]
./test[0x40086a]

This shows the load module, offset, and function that each frame in the stack came from. Here you can see the signal handler on top of the stack, and the libc functions before main in addition to main, foo, bar, and baz.

@CesarB 2008-10-23 15:05:15

There's also /lib/libSegFault.so which you can use with LD_PRELOAD.

@jschmier 2010-03-27 19:11:24

It looks like the first two entries in your backtrace output contain a return address inside the signal handler and probably one inside sigaction() in libc. While your backtrace appears to be correct, I have sometimes found that additional steps are necessary to ensure the actual location of the fault appears in the backtrace as it can be overwritten with sigaction() by the kernel.

@Johannes Hoff 2011-08-31 09:50:28

I can confirm that this (the original reply) works on OS X.

@Mattias Nilsson 2012-04-17 06:39:25

What would happen if the crash comes from inside malloc? Wouldn't you then hold a lock and then get stuck as "backtrace" tries to allocate memory?

@Todd Gamblin 2012-04-18 00:19:36

You could then try some other stackwalking API, e.g.: DynInst's StackwalkerAPI dyninst.org/stackwalkerapi or nongnu.org/libunwind. Generally if you expect to walk out of stack frames or interrupt frames inside malloc, you need to do special things to handle it. Many tools use their own arena allocator to avoid conflicting with the libc malloc in situations like this.

@Parag Bafna 2012-06-14 07:45:13

backtrace and backtrace_symbols_fd are not async-signal-safe. you should not use these function in signal handler.

@lurscher 2012-10-19 02:16:29

@ParagBafna, then what can we use for backtraces that is async-signal safe?

@Matt Clarkson 2013-01-30 10:45:32

catchsegv is not what the OP needs but is awesome for catching segmentation faults and getting all the information.

@jfritz42 2013-04-10 20:17:47

For ARM, I had to also compile with -funwind-tables. Otherwise my stack depth was always 1 (empty).

@Carl Norum 2013-05-30 17:35:45

You can't call exit() safely from a signal handler. Use _exit() or _Exit().

@ducin 2014-01-20 10:27:31

@Olshansk - the same with me

@Paul Coccoli 2014-03-05 14:17:27

Using an exit function prevents you from getting a core dump and masks the reason for exiting from the parents wait call. I usually set SA_RESETHAND to unset my sigaction signal handler after it runs, then call raise(sig) to re-raise the signal. If core dumps are enabled, then you'll get both the backtrace and the core dump.

@Marco83 2014-05-22 09:46:46

If you are planning to use the above code somewhere else than in a function that eventually exit(), please note that per backtrace_symbol_fd(3), you need to free the the array after you are done with it.

@mic_e 2014-08-19 12:18:38

According to man 7 signal, Every single one of the functions that your handler calls is not async-signal-safe, leading to undefined behaviour. In practice, your process might deadlock (with -lpthread), or corrupt its memory (without).

@Todd Gamblin 2014-08-22 23:19:33

@mic_e: True! But this is a handler to call when your application crashes. In other words, your process has already bitten the dust, and you are in very unsafe territory. You call this in a signal handler because you want to know where the error happened, and it works in practice. If it fails (and I have not seen that happen often), you've lost nothing because your process was already dying to begin with.

@Yaroslav Bulatov 2014-09-01 22:25:11

I confirm that it works with g++4.2/MacOS 10.9.4

@sree 2015-07-24 07:18:36

@anyone, how to generate stacktrace (in my logs) and coredump together? If we define a signal handler then we will not get coredump. I want both, suggest me a good solution. Thanks in advance.

@Todd Gamblin 2015-07-24 08:22:04

@sree: You need to add some code so that the handler unregisters itself and reverts to default signal handling, then kills itself. Adding "signal(sig, SIG_DFL); kill(getpid(), sig);" at the end of the handler should work. Example here: alexonlinux.com/…

@sree 2015-07-25 12:33:11

@tgamblin: I had tried this technique but its completely pointing to a wrong location when I do hit a crash! :(; But my backtrace() works fine, its pointing to the exact location. But I need to have a coredump with the exact informoation along with the backtrace printed into my logs. And what are all the disadvantage my program would endup by using signal(signum, SIG_DFL)? Thank you for your Answer.

@Jack 2016-02-06 20:29:21

Is there an alternative for windows?

@user2763554 2016-11-17 03:57:48

*(int*)0=1; would be suffice to generate segfault instead of 2 lines

@Giel 2018-06-07 14:41:22

@sree for SIGSEGV, SIGILL, SIGFPE and SIGBUS just returning from the signal handler will re-raise the signal at the original location, thus giving you a decent core dump. For SIGABRT the same will happen if and only if you received it as a result of abort(). As an other option: try registering your signal handler with sigaction without using SA_NODEFER (signal is usually equivalent to SA_RESETHAND | SA_NODEFER). The signal will then only be delivered after returning from the signal handler.

@jard18 2013-12-12 23:23:10

I have seen a lot of answers here performing a signal handler and then exiting. That's the way to go, but remember a very important fact: If you want to get the core dump for the generated error, you can't call exit(status). Call abort() instead!

@jschmier 2009-12-18 00:05:42

Linux

While the use of the backtrace() functions in execinfo.h to print a stacktrace and exit gracefully when you get a segmentation fault has already been suggested, I see no mention of the intricacies necessary to ensure the resulting backtrace points to the actual location of the fault (at least for some architectures - x86 & ARM).

The first two entries in the stack frame chain when you get into the signal handler contain a return address inside the signal handler and one inside sigaction() in libc. The stack frame of the last function called before the signal (which is the location of the fault) is lost.

Code

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#ifndef __USE_GNU
#define __USE_GNU
#endif

#include <execinfo.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ucontext.h>
#include <unistd.h>

/* This structure mirrors the one found in /usr/include/asm/ucontext.h */
typedef struct _sig_ucontext {
 unsigned long     uc_flags;
 struct ucontext   *uc_link;
 stack_t           uc_stack;
 struct sigcontext uc_mcontext;
 sigset_t          uc_sigmask;
} sig_ucontext_t;

void crit_err_hdlr(int sig_num, siginfo_t * info, void * ucontext)
{
 void *             array[50];
 void *             caller_address;
 char **            messages;
 int                size, i;
 sig_ucontext_t *   uc;

 uc = (sig_ucontext_t *)ucontext;

 /* Get the address at the time the signal was raised */
#if defined(__i386__) // gcc specific
 caller_address = (void *) uc->uc_mcontext.eip; // EIP: x86 specific
#elif defined(__x86_64__) // gcc specific
 caller_address = (void *) uc->uc_mcontext.rip; // RIP: x86_64 specific
#else
#error Unsupported architecture. // TODO: Add support for other arch.
#endif

 fprintf(stderr, "signal %d (%s), address is %p from %p\n", 
  sig_num, strsignal(sig_num), info->si_addr, 
  (void *)caller_address);

 size = backtrace(array, 50);

 /* overwrite sigaction with caller's address */
 array[1] = caller_address;

 messages = backtrace_symbols(array, size);

 /* skip first stack frame (points here) */
 for (i = 1; i < size && messages != NULL; ++i)
 {
  fprintf(stderr, "[bt]: (%d) %s\n", i, messages[i]);
 }

 free(messages);

 exit(EXIT_FAILURE);
}

int crash()
{
 char * p = NULL;
 *p = 0;
 return 0;
}

int foo4()
{
 crash();
 return 0;
}

int foo3()
{
 foo4();
 return 0;
}

int foo2()
{
 foo3();
 return 0;
}

int foo1()
{
 foo2();
 return 0;
}

int main(int argc, char ** argv)
{
 struct sigaction sigact;

 sigact.sa_sigaction = crit_err_hdlr;
 sigact.sa_flags = SA_RESTART | SA_SIGINFO;

 if (sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL) != 0)
 {
  fprintf(stderr, "error setting signal handler for %d (%s)\n",
    SIGSEGV, strsignal(SIGSEGV));

  exit(EXIT_FAILURE);
 }

 foo1();

 exit(EXIT_SUCCESS);
}

Output

signal 11 (Segmentation fault), address is (nil) from 0x8c50
[bt]: (1) ./test(crash+0x24) [0x8c50]
[bt]: (2) ./test(foo4+0x10) [0x8c70]
[bt]: (3) ./test(foo3+0x10) [0x8c8c]
[bt]: (4) ./test(foo2+0x10) [0x8ca8]
[bt]: (5) ./test(foo1+0x10) [0x8cc4]
[bt]: (6) ./test(main+0x74) [0x8d44]
[bt]: (7) /lib/libc.so.6(__libc_start_main+0xa8) [0x40032e44]

All the hazards of calling the backtrace() functions in a signal handler still exist and should not be overlooked, but I find the functionality I described here quite helpful in debugging crashes.

It is important to note that the example I provided is developed/tested on Linux for x86. I have also successfully implemented this on ARM using uc_mcontext.arm_pc instead of uc_mcontext.eip.

Here's a link to the article where I learned the details for this implementation: http://www.linuxjournal.com/article/6391

@jschmier 2010-03-26 20:00:26

On systems using GNU ld, remember to compile with -rdynamic to instruct the linker to add all symbols, not only used ones, to the dynamic symbol table. This allows backtrace_symbols() to convert addresses to function names

@jschmier 2010-05-24 23:54:03

The output in the example above was taken from an test program compiled using a gcc-3.4.5-glibc-2.3.6 cross-toolchain and executed on an ARMv6-based platform running Linux Kernel 2.6.22.

@manav m-n 2011-10-17 06:58:01

enabling backtrace support is only meaningful when compiling for the Thumb mode in ARM

@qehgt 2012-02-01 15:53:22

Also, you need to add "-mapcs-frame" option to GCC''s command line to generate stack frames on ARM platform

@Ulterior 2012-05-18 08:43:27

This is a gem to be found

@enthusiasticgeek 2012-10-24 18:26:08

This may be too late but can we use addr2line command somehow to get the exact line where the crash occurred?

@mmlb 2012-12-14 14:57:31

On more recent builds of glibc uc_mcontext does not contain a field named eip. There is now an array that needs to be indexed, uc_mcontext.gregs[REG_EIP] is the equivalent.

@arr_sea 2013-04-04 03:26:55

@enthusiasticgeek, I created a little bash script to feed the output of jschmier's 2nd answer into the addr2line utility. Thanks for drawing my attention to that tool! See: stackoverflow.com/a/15801966/1797414

@jfritz42 2013-04-10 16:10:48

For ARM, my backtraces always had depth 1 until I added the -funwind-tables option to the compiler.

@jschmier 2017-01-18 23:45:31

@letmaik, it's been a while since I took a crack at this, but in x86_64, the instruction pointer is RIP, not EIP. Perhaps you need to index the uc_mcontext array as uc_mcontext.gregs[REG_RIP].

@Leedehai 2018-10-10 07:02:52

struct sigcontext cannot be found by macOS 10.14, which is POSIX-compliant, so this is a glibc-specific program. Also, on Ubuntu 16.04 (Linux 4.4.0 as kernel), the line containing the symbol of crash() appears twice, instead of only once as displayed in the answer.

@Steven Lu 2019-11-21 00:41:34

On x86_64 (Ubuntu 18.04) This statement does not appear to apply? The stack frame of the last function called before the signal (which is the location of the fault) is lost. Without injecting the pointer obtained through uc_mcontext, the location of the segfault is shown as the fourth entry in the backtrace.

@enthusiasticgeek 2013-05-08 19:13:58

In addition to above answers, here how you make Debian Linux OS generate core dump

  1. Create a “coredumps” folder in the user's home folder
  2. Go to /etc/security/limits.conf. Below the ' ' line, type “ soft core unlimited”, and “root soft core unlimited” if enabling core dumps for root, to allow unlimited space for core dumps.
  3. NOTE: “* soft core unlimited” does not cover root, which is why root has to be specified in its own line.
  4. To check these values, log out, log back in, and type “ulimit -a”. “Core file size” should be set to unlimited.
  5. Check the .bashrc files (user, and root if applicable) to make sure that ulimit is not set there. Otherwise, the value above will be overwritten on startup.
  6. Open /etc/sysctl.conf. Enter the following at the bottom: “kernel.core_pattern = /home//coredumps/%e_%t.dump”. (%e will be the process name, and %t will be the system time)
  7. Exit and type “sysctl -p” to load the new configuration Check /proc/sys/kernel/core_pattern and verify that this matches what you just typed in.
  8. Core dumping can be tested by running a process on the command line (“ &”), and then killing it with “kill -11 ”. If core dumping is successful, you will see “(core dumped)” after the segmentation fault indication.

@arr_sea 2013-04-04 03:21:22

Thank you to enthusiasticgeek for drawing my attention to the addr2line utility.

I've written a quick and dirty script to process the output of the answer provided here: (much thanks to jschmier!) using the addr2line utility.

The script accepts a single argument: The name of the file containing the output from jschmier's utility.

The output should print something like the following for each level of the trace:

BACKTRACE:  testExe 0x8A5db6b
FILE:       pathToFile/testExe.C:110
FUNCTION:   testFunction(int) 
   107  
   108           
   109           int* i = 0x0;
  *110           *i = 5;
   111      
   112        }
   113        return i;

Code:

#!/bin/bash

LOGFILE=$1

NUM_SRC_CONTEXT_LINES=3

old_IFS=$IFS  # save the field separator           
IFS=$'\n'     # new field separator, the end of line           

for bt in `cat $LOGFILE | grep '\[bt\]'`; do
   IFS=$old_IFS     # restore default field separator 
   printf '\n'
   EXEC=`echo $bt | cut -d' ' -f3 | cut -d'(' -f1`  
   ADDR=`echo $bt | cut -d'[' -f3 | cut -d']' -f1`
   echo "BACKTRACE:  $EXEC $ADDR"
   A2L=`addr2line -a $ADDR -e $EXEC -pfC`
   #echo "A2L:        $A2L"

   FUNCTION=`echo $A2L | sed 's/\<at\>.*//' | cut -d' ' -f2-99`
   FILE_AND_LINE=`echo $A2L | sed 's/.* at //'`
   echo "FILE:       $FILE_AND_LINE"
   echo "FUNCTION:   $FUNCTION"

   # print offending source code
   SRCFILE=`echo $FILE_AND_LINE | cut -d':' -f1`
   LINENUM=`echo $FILE_AND_LINE | cut -d':' -f2`
   if ([ -f $SRCFILE ]); then
      cat -n $SRCFILE | grep -C $NUM_SRC_CONTEXT_LINES "^ *$LINENUM\>" | sed "s/ $LINENUM/*$LINENUM/"
   else
      echo "File not found: $SRCFILE"
   fi
   IFS=$'\n'     # new field separator, the end of line           
done

IFS=$old_IFS     # restore default field separator 

@markhor 2013-03-01 06:38:05

You can use DeathHandler - small C++ class which does everything for you, reliable.

@example 2014-08-26 14:39:58

unfortunately it uses execlp() to perform addr2line calls... would be nice to fully stay in the own program (which is possible by including the addr2line code in some form)

@jschmier 2010-03-26 19:52:15

Even though a correct answer has been provided that describes how to use the GNU libc backtrace() function1 and I provided my own answer that describes how to ensure a backtrace from a signal handler points to the actual location of the fault2, I don't see any mention of demangling C++ symbols output from the backtrace.

When obtaining backtraces from a C++ program, the output can be run through c++filt1 to demangle the symbols or by using abi::__cxa_demangle1 directly.

  • 1 Linux & OS X Note that c++filt and __cxa_demangle are GCC specific
  • 2 Linux

The following C++ Linux example uses the same signal handler as my other answer and demonstrates how c++filt can be used to demangle the symbols.

Code:

class foo
{
public:
    foo() { foo1(); }

private:
    void foo1() { foo2(); }
    void foo2() { foo3(); }
    void foo3() { foo4(); }
    void foo4() { crash(); }
    void crash() { char * p = NULL; *p = 0; }
};

int main(int argc, char ** argv)
{
    // Setup signal handler for SIGSEGV
    ...

    foo * f = new foo();
    return 0;
}

Output (./test):

signal 11 (Segmentation fault), address is (nil) from 0x8048e07
[bt]: (1) ./test(crash__3foo+0x13) [0x8048e07]
[bt]: (2) ./test(foo4__3foo+0x12) [0x8048dee]
[bt]: (3) ./test(foo3__3foo+0x12) [0x8048dd6]
[bt]: (4) ./test(foo2__3foo+0x12) [0x8048dbe]
[bt]: (5) ./test(foo1__3foo+0x12) [0x8048da6]
[bt]: (6) ./test(__3foo+0x12) [0x8048d8e]
[bt]: (7) ./test(main+0xe0) [0x8048d18]
[bt]: (8) ./test(__libc_start_main+0x95) [0x42017589]
[bt]: (9) ./test(__register_frame_info+0x3d) [0x8048981]

Demangled Output (./test 2>&1 | c++filt):

signal 11 (Segmentation fault), address is (nil) from 0x8048e07
[bt]: (1) ./test(foo::crash(void)+0x13) [0x8048e07]
[bt]: (2) ./test(foo::foo4(void)+0x12) [0x8048dee]
[bt]: (3) ./test(foo::foo3(void)+0x12) [0x8048dd6]
[bt]: (4) ./test(foo::foo2(void)+0x12) [0x8048dbe]
[bt]: (5) ./test(foo::foo1(void)+0x12) [0x8048da6]
[bt]: (6) ./test(foo::foo(void)+0x12) [0x8048d8e]
[bt]: (7) ./test(main+0xe0) [0x8048d18]
[bt]: (8) ./test(__libc_start_main+0x95) [0x42017589]
[bt]: (9) ./test(__register_frame_info+0x3d) [0x8048981]

The following builds on the signal handler from my original answer and can replace the signal handler in the above example to demonstrate how abi::__cxa_demangle can be used to demangle the symbols. This signal handler produces the same demangled output as the above example.

Code:

void crit_err_hdlr(int sig_num, siginfo_t * info, void * ucontext)
{
    sig_ucontext_t * uc = (sig_ucontext_t *)ucontext;

    void * caller_address = (void *) uc->uc_mcontext.eip; // x86 specific

    std::cerr << "signal " << sig_num 
              << " (" << strsignal(sig_num) << "), address is " 
              << info->si_addr << " from " << caller_address 
              << std::endl << std::endl;

    void * array[50];
    int size = backtrace(array, 50);

    array[1] = caller_address;

    char ** messages = backtrace_symbols(array, size);    

    // skip first stack frame (points here)
    for (int i = 1; i < size && messages != NULL; ++i)
    {
        char *mangled_name = 0, *offset_begin = 0, *offset_end = 0;

        // find parantheses and +address offset surrounding mangled name
        for (char *p = messages[i]; *p; ++p)
        {
            if (*p == '(') 
            {
                mangled_name = p; 
            }
            else if (*p == '+') 
            {
                offset_begin = p;
            }
            else if (*p == ')')
            {
                offset_end = p;
                break;
            }
        }

        // if the line could be processed, attempt to demangle the symbol
        if (mangled_name && offset_begin && offset_end && 
            mangled_name < offset_begin)
        {
            *mangled_name++ = '\0';
            *offset_begin++ = '\0';
            *offset_end++ = '\0';

            int status;
            char * real_name = abi::__cxa_demangle(mangled_name, 0, 0, &status);

            // if demangling is successful, output the demangled function name
            if (status == 0)
            {    
                std::cerr << "[bt]: (" << i << ") " << messages[i] << " : " 
                          << real_name << "+" << offset_begin << offset_end 
                          << std::endl;

            }
            // otherwise, output the mangled function name
            else
            {
                std::cerr << "[bt]: (" << i << ") " << messages[i] << " : " 
                          << mangled_name << "+" << offset_begin << offset_end 
                          << std::endl;
            }
            free(real_name);
        }
        // otherwise, print the whole line
        else
        {
            std::cerr << "[bt]: (" << i << ") " << messages[i] << std::endl;
        }
    }
    std::cerr << std::endl;

    free(messages);

    exit(EXIT_FAILURE);
}

@arr_sea 2013-04-05 19:02:22

Thank you for this, jschmier. I created a little bash script to feed the output of this into the addr2line utility. See: stackoverflow.com/a/15801966/1797414

@Bamaco 2014-07-07 19:52:41

Don't forget to #include <cxxabi.h>

@kevinf 2014-10-23 20:25:29

Good documentation, and a straightforward header file has been posted here since 2008... panthema.net/2008/0901-stacktrace-demangled very similar to your approach :)

@orcy 2015-11-27 06:41:15

abi::__cxa_demangle seems to be not the async-signal-safe, so the signal handler can deadlock somewhere in malloc.

@Gregory 2008-09-18 02:55:24

Ive been looking at this problem for a while.

And buried deep in the Google Performance Tools README

http://code.google.com/p/google-perftools/source/browse/trunk/README

talks about libunwind

http://www.nongnu.org/libunwind/

Would love to hear opinions of this library.

The problem with -rdynamic is that it can increase the size of the binary relatively significantly in some cases

@Dan 2010-03-24 06:46:47

On x86/64, I have not seen -rdynamic increase binary size much. Adding -g makes for a much bigger increase.

@Herbert 2014-11-24 20:10:04

I noticed that libunwind does not have functionality to get the line number, and I guess (did not test) unw_get_proc_name returns the function symbol (which is obfuscated for overloading and such) instead of the original name.

@Gregory 2014-11-25 20:53:14

That's correct. It gets very tricky to do this correctly, but I've had excellent success with gaddr2line there is lots of practical information here blog.bigpixel.ro/2010/09/stack-unwinding-stack-trace-with-gc‌​c

@Adam Mitz 2008-09-17 00:07:57

See the Stack Trace facility in ACE (ADAPTIVE Communication Environment). It's already written to cover all major platforms (and more). The library is BSD-style licensed so you can even copy/paste the code if you don't want to use ACE.

@tglas 2019-12-01 19:48:03

The link seem to be dead.

@Joseph 2008-09-16 21:24:29

I forgot about the GNOME tech of "apport", but I don't know much about using it. It is used to generate stacktraces and other diagnostics for processing and can automatically file bugs. It's certainly worth checking in to.

@Kasprzol 2008-09-16 21:16:42

On Linux/unix/MacOSX use core files (you can enable them with ulimit or compatible system call). On Windows use Microsoft error reporting (you can become a partner and get access to your application crash data).

@INS 2008-09-16 21:09:52

*nix: you can intercept SIGSEGV (usualy this signal is raised before crashing) and keep the info into a file. (besides the core file which you can use to debug using gdb for example).

win: Check this from msdn.

You can also look at the google's chrome code to see how it handles crashes. It has a nice exception handling mechanism.

@IInspectable 2018-02-17 14:28:29

SEH does not help in producing a stack trace. While it could be part of a solution, that solution is harder to implement and provides less information at the expense of disclosing more information about your application than the real solution: Write a mini dump. And set up Windows to do this automatically for you.

@terminus 2008-09-16 21:01:04

I can help with the Linux version: the function backtrace, backtrace_symbols and backtrace_symbols_fd can be used. See the corresponding manual pages.

@Jim Buck 2008-09-16 21:00:42

I would use the code that generates a stack trace for leaked memory in Visual Leak Detector. This only works on Win32, though.

@IInspectable 2018-02-17 14:29:36

And requires that you ship debug symbols with your code. In general not desirable. Write a mini dump and set up Windows to do it automatically for you on unhandled exceptions.

@Benson 2008-09-16 20:57:12

It's important to note that once you generate a core file you'll need to use the gdb tool to look at it. For gdb to make sense of your core file, you must tell gcc to instrument the binary with debugging symbols: to do this, you compile with the -g flag:

$ g++ -g prog.cpp -o prog

Then, you can either set "ulimit -c unlimited" to let it dump a core, or just run your program inside gdb. I like the second approach more:

$ gdb ./prog
... gdb startup output ...
(gdb) run
... program runs and crashes ...
(gdb) where
... gdb outputs your stack trace ...

I hope this helps.

@Vi. 2010-06-30 22:20:57

You can also call gdb right from your crashing program. Setup handler for SIGSEGV, SEGILL, SIGBUS, SIGFPE that will call gdb. Details: stackoverflow.com/questions/3151779/… The advantage is that you get beautiful, annotated backtrace like in bt full, also you can get stack traces of all threads.

@baziorek 2019-01-02 08:00:13

You can also get backtrace easier than in the answer: gdb -silent ./prog core --eval-command=backtrace --batch -it would show backtrace and close debugger

@Stéphane 2008-09-16 20:55:21

Look at:

man 3 backtrace

And:

#include <exeinfo.h>
int backtrace(void **buffer, int size);

These are GNU extensions.

@Stéphane 2010-10-10 07:05:17

There may be additional examples to help out on this page I created a while back: charette.no-ip.com:81/programming/2010-01-25_Backtrace

@mana 2008-09-16 20:47:19

ulimit -c unlimited

is a system variable, wich will allow to create a core dump after your application crashes. In this case an unlimited amount. Look for a file called core in the very same directory. Make sure you compiled your code with debugging informations enabled!

regards

@Todd Gamblin 2008-09-16 20:54:12

The user is not asking for a core dump. He's asking for a stack trace. See delorie.com/gnu/docs/glibc/libc_665.html

@Mo. 2008-09-16 20:57:06

a core dump will contain the call stack at the moment of the crash, won't it?

@Paul Tomblin 2008-09-16 20:58:09

You're assuming he's on Unix, and using Bash.

@sivabudh 2010-11-10 19:46:26

If you are using tcsh, you have to do limit coredumpsize unlimited

@Stephen Deken 2008-09-16 20:51:24

Some versions of libc contain functions that deal with stack traces; you might be able to use them:

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

I remember using libunwind a long time ago to get stack traces, but it may not be supported on your platform.

Related Questions

Sponsored Content

6 Answered Questions

7 Answered Questions

30 Answered Questions

[SOLVED] How do I obtain crash-data from my Android application?

23 Answered Questions

[SOLVED] Compiling an application for use in highly radioactive environments

8 Answered Questions

[SOLVED] What does int argc, char *argv[] mean?

2 Answered Questions

3 Answered Questions

[SOLVED] Can an application programmatically generate its own stacktrace?

  • 2011-11-07 01:05:28
  • vy32
  • 1979 View
  • 14 Score
  • 3 Answer
  • Tags:   c stack-trace

1 Answered Questions

[SOLVED] Simple program crashes

  • 2012-08-15 19:31:58
  • Alex
  • 2395 View
  • 11 Score
  • 1 Answer
  • Tags:   c++ gcc crash g++

1 Answered Questions

Sponsored Content