How to automatically generate a stacktrace when my program crashes

Question

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  amp  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  lt execinfo h gt   include  lt signal h gt   include  lt stdio h gt   include  lt stdlib h gt   include  lt string h gt   include  lt ucontext h gt   include  lt unistd h gt      This structure mirrors the one found in  usr include asm ucontext h    typedef struct  sig ucontext    unsigned long     uc flags   ucontext t         uc link   stack t           uc stack   sigcontext t      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- gt uc mcontext eip     EIP  x86 specific  elif defined   x86 64       gcc specific  caller address    void    uc- gt uc mcontext rip     RIP  x86 64 specific  else  error Unsupported architecture     TODO  Add support for other arch   endif   fprintf stderr   quot signal  d   s   address is  p from  p n quot      sig num  strsignal sig num   info- gt 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  lt  size  amp  amp  messages    NULL    i       fprintf stderr   quot  bt     d   s n quot   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   amp sigact   struct sigaction   NULL     0       fprintf stderr   quot error setting signal handler for  d   s  n quot       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

User · Answer

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  amp  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 gt  amp 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- gt uc mcontext eip     x86 specific      std  cerr  lt  lt   signal    lt  lt  sig num                 lt  lt        lt  lt  strsignal sig num   lt  lt      address is                   lt  lt  info- gt si addr  lt  lt    from    lt  lt  caller address                 lt  lt  std  endl  lt  lt  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  lt  size  amp  amp  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  amp  amp  offset begin  amp  amp  offset end  amp  amp               mangled name  lt  offset begin                         mangled name       0                offset begin       0                offset end       0                int status              char   real name   abi    cxa demangle mangled name  0  0   amp status                   if demangling is successful  output the demangled function name             if  status    0                                    std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt                                    lt  lt  real name  lt  lt       lt  lt  offset begin  lt  lt  offset end                             lt  lt  std  endl                                otherwise  output the mangled function name             else                               std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt                                    lt  lt  mangled name  lt  lt       lt  lt  offset begin  lt  lt  offset end                             lt  lt  std  endl                            free real name                        otherwise  print the whole line         else                       std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt  std  endl                      std  cerr  lt  lt  std  endl       free messages        exit EXIT FAILURE

User · Answer

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  amp  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 gt  amp 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- gt uc mcontext eip     x86 specific      std  cerr  lt  lt   signal    lt  lt  sig num                 lt  lt        lt  lt  strsignal sig num   lt  lt      address is                   lt  lt  info- gt si addr  lt  lt    from    lt  lt  caller address                 lt  lt  std  endl  lt  lt  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  lt  size  amp  amp  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  amp  amp  offset begin  amp  amp  offset end  amp  amp               mangled name  lt  offset begin                         mangled name       0                offset begin       0                offset end       0                int status              char   real name   abi    cxa demangle mangled name  0  0   amp status                   if demangling is successful  output the demangled function name             if  status    0                                    std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt                                    lt  lt  real name  lt  lt       lt  lt  offset begin  lt  lt  offset end                             lt  lt  std  endl                                otherwise  output the mangled function name             else                               std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt                                    lt  lt  mangled name  lt  lt       lt  lt  offset begin  lt  lt  offset end                             lt  lt  std  endl                            free real name                        otherwise  print the whole line         else                       std  cerr  lt  lt    bt       lt  lt  i  lt  lt        lt  lt  messages i   lt  lt  std  endl                      std  cerr  lt  lt  std  endl       free messages        exit EXIT FAILURE

User · Answer

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

User · Answer

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

User · Answer

I can help with the Linux version  the function backtrace  backtrace symbols and backtrace symbols fd can be used  See the corresponding manual pages

User · Answer

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  lt iostream gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt   include  lt string gt   include  lt cassert gt   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  lt  lt   sig seg fault handler   lt  lt  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  lt  lt   stack trace     lt  lt  endl    backtrace symbols fd array  size  STDERR FILENO     cerr  lt  lt   resend SIGSEGV to get core dump   lt  lt  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  amp sigseg stack  nullptr      sigseg handler sa flags   SA ONSTACK   else   sigseg handler sa flags   SA RESTART     endif   sigseg handler sa handler    amp handler    assert  sigaction SIGSEGV   amp sigseg handler  nullptr      cout  lt  lt   sig action set   lt  lt  endl    foo      return 0

User · Answer

ulimit -c  lt value gt  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

User · Answer

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

User · Answer

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

User · Answer

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  lt stdio h gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt    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

User · Answer

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

User · Answer

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  lt filesystem gt   include  lt sstream gt   include  lt fstream gt   include  lt signal h gt           signal    raise  include  lt boost stacktrace hpp gt   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  lt  lt  st  lt  lt  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

User · Answer

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   Effective minidumps Effective minidumps  Part 2

User · Answer

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

User · Answer

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

User · Answer

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   lt at  gt         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  gt     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

User · Answer

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

User · Answer

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

User · Answer

In addition to above answers  here how you make Debian Linux OS generate core dump    Create a    coredumps    folder in the user s home folder 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   NOTE       soft core unlimited    does not cover root  which is why root has to be specified in its own line  To check these values  log out  log back in  and type    ulimit -a        Core file size    should be set to unlimited  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  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  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  Core dumping can be tested by running a process on the command line       amp       and then killing it with    kill -11      If core dumping is successful  you will see     core dumped     after the segmentation fault indication

User · Answer

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   lt at  gt         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  gt     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

User · Answer

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   Effective minidumps Effective minidumps  Part 2

User · Answer

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

User · Answer

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

User · Answer

I can help with the Linux version  the function backtrace  backtrace symbols and backtrace symbols fd can be used  See the corresponding manual pages

User · Answer

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

User · Answer

I can help with the Linux version  the function backtrace  backtrace symbols and backtrace symbols fd can be used  See the corresponding manual pages

User · Answer

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  lt stdio h gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt    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

User · Answer

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  lt stdio h gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt    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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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    Compile your program with  -g  flag for embedding debug symbols to binary  don t worry this will not impact your performance    On linux run next command   ulimit -c unlimited  - to allow system make big crash dumps  When your program crashed  in the working directory you will see file  core   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

User · Answer

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

User · Answer

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

User · Answer

ulimit -c  lt value gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Look at   man 3 backtrace  And    include  lt exeinfo h gt  int backtrace void   buffer  int size     These are GNU extensions

User · Answer

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

User · Answer

ulimit -c  lt value gt  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

User · Answer

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

User · Answer

Look at   man 3 backtrace  And    include  lt exeinfo h gt  int backtrace void   buffer  int size     These are GNU extensions

User · Answer

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

User · Answer

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    Compile your program with  -g  flag for embedding debug symbols to binary  don t worry this will not impact your performance    On linux run next command   ulimit -c unlimited  - to allow system make big crash dumps  When your program crashed  in the working directory you will see file  core   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

User · Answer

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  lt stdio h gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt    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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  lt filesystem gt   include  lt sstream gt   include  lt fstream gt   include  lt signal h gt           signal    raise  include  lt boost stacktrace hpp gt   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  lt  lt  st  lt  lt  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

User · Answer

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  amp  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  lt execinfo h gt   include  lt signal h gt   include  lt stdio h gt   include  lt stdlib h gt   include  lt string h gt   include  lt ucontext h gt   include  lt unistd h gt      This structure mirrors the one found in  usr include asm ucontext h    typedef struct  sig ucontext    unsigned long     uc flags   ucontext t         uc link   stack t           uc stack   sigcontext t      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- gt uc mcontext eip     EIP  x86 specific  elif defined   x86 64       gcc specific  caller address    void    uc- gt uc mcontext rip     RIP  x86 64 specific  else  error Unsupported architecture     TODO  Add support for other arch   endif   fprintf stderr   quot signal  d   s   address is  p from  p n quot      sig num  strsignal sig num   info- gt 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  lt  size  amp  amp  messages    NULL    i       fprintf stderr   quot  bt     d   s n quot   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   amp sigact   struct sigaction   NULL     0       fprintf stderr   quot error setting signal handler for  d   s  n quot       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

User · Answer

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

User · Answer

ulimit -c  lt value gt  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

User · Answer

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     Run within catchsegv     catchsegv program -o hai  Link with libSegFault at runtime     LD PRELOAD  lib libSegFault so program -o hai  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

User · Answer

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

User · Answer

I can help with the Linux version  the function backtrace  backtrace symbols and backtrace symbols fd can be used  See the corresponding manual pages

User · Answer

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

User · Answer

Look at   man 3 backtrace  And    include  lt exeinfo h gt  int backtrace void   buffer  int size     These are GNU extensions

User · Answer

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

User · Answer

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  lt iostream gt   include  lt execinfo h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt unistd h gt   include  lt string gt   include  lt cassert gt   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  lt  lt   sig seg fault handler   lt  lt  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  lt  lt   stack trace     lt  lt  endl    backtrace symbols fd array  size  STDERR FILENO     cerr  lt  lt   resend SIGSEGV to get core dump   lt  lt  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  amp sigseg stack  nullptr      sigseg handler sa flags   SA ONSTACK   else   sigseg handler sa flags   SA RESTART     endif   sigseg handler sa handler    amp handler    assert  sigaction SIGSEGV   amp sigseg handler  nullptr      cout  lt  lt   sig action set   lt  lt  endl    foo      return 0

User · Answer

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     Run within catchsegv     catchsegv program -o hai  Link with libSegFault at runtime     LD PRELOAD  lib libSegFault so program -o hai  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Look at   man 3 backtrace  And    include  lt exeinfo h gt  int backtrace void   buffer  int size     These are GNU extensions

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

In addition to above answers  here how you make Debian Linux OS generate core dump    Create a    coredumps    folder in the user s home folder 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   NOTE       soft core unlimited    does not cover root  which is why root has to be specified in its own line  To check these values  log out  log back in  and type    ulimit -a        Core file size    should be set to unlimited  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  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  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  Core dumping can be tested by running a process on the command line       amp       and then killing it with    kill -11      If core dumping is successful  you will see     core dumped     after the segmentation fault indication

[c++] How to automatically generate a stacktrace when my program crashes

Examples related to c++

Examples related to gcc

Examples related to crash

Examples related to stack-trace

Examples related to assert