print call stack in C or C

Question

Is there any way to dump the call stack in a running process in C or C   every time a certain function is called   What I have in mind is something like this   void foo        print stack trace           foo s body     return     Where print stack trace works similarly to caller in Perl   Or something like this   int main  void           will print out debug info every time foo   is called     register stack trace function foo            etc        where register stack trace function puts some sort of internal breakpoint that will cause a stack trace to be printed whenever foo is called   Does anything like this exist in some standard C library   I am working on Linux  using GCC     Background  I have a test run that behaves differently based on some commandline switches that shouldn t affect this behavior   My code has a pseudo-random number generator that I assume is being called differently based on these switches   I want to be able to run the test with each set of switches and see if the random number generator is called differently for each one

User · Answer

Of course the next question is  will this be enough    The main disadvantage of stack-traces is that why you have the precise function being called you do not have anything else  like the value of its arguments  which is very useful for debugging   If you have access to gcc and gdb  I would suggest using assert to check for a specific condition  and produce a memory dump if it is not met  Of course this means the process will stop  but you ll have a full fledged report instead of a mere stack-trace   If you wish for a less obtrusive way  you can always use logging  There are very efficient logging facilities out there  like Pantheios for example  Which once again could give you a much more accurate image of what is going on

User · Answer

For a linux-only solution you can use backtrace 3  that simply returns an array of void    in fact each of these point to the return address from the corresponding stack frame   To translate these to something of use  there s backtrace symbols 3    Pay attention to the notes section in backtrace 3       The symbol names may be unavailable   without the use of special linker   options           For systems using the GNU linker  it is necessary to use the   -rdynamic linker          option   Note that names of  static  functions are not exposed    and won t be          available in the backtrace

User · Answer

You can implement the functionality yourself   Use a global  string stack and at start of each function push the function name and such other values  eg parameters  onto this stack  at exit of function pop it again   Write a function that will printout the stack content when it is called  and use this in the function where you want to see the callstack   This may sound like a lot of work but is quite useful

User · Answer

Another answer to an old thread   When I need to do this  I usually just use system   and pstack  So something like this    include  lt sys types h gt   include  lt unistd h gt   include  lt string gt   include  lt sstream gt   include  lt cstdlib gt   void f         pid t myPid   getpid        std  string pstackCommand    pstack        std  stringstream ss      ss  lt  lt  myPid      pstackCommand    ss str        system pstackCommand c str        void g        f        void h        g       int main        h        This outputs   0  0x00002aaaab62d61e in waitpid    from  lib64 libc so 6  1  0x00002aaaab5bf609 in do system    from  lib64 libc so 6  2  0x0000000000400c3c in f       3  0x0000000000400cc5 in g       4  0x0000000000400cd1 in h       5  0x0000000000400cdd in main      This should work on Linux  FreeBSD and Solaris  I don t think that macOS has pstack or a simple equivalent  but this thread seems to have an alternative   If you are using C  then you will need to use C string functions    include  lt sys types h gt   include  lt unistd h gt   include  lt stdlib h gt   include  lt stdio h gt   void f         pid t myPid   getpid                 length of command 7 for  pstack    7 for the PID  1 for nul            char pstackCommand 7 7 1       sprintf pstackCommand   pstack  d    int myPid       system pstackCommand       I ve used 7 for the max number of digits in the PID  based on this post

User · Answer

You can use the Boost libraries to print the current callstack    include  lt boost stacktrace hpp gt          somewhere inside the  bar int   function that is called recursively  std  cout  lt  lt  boost  stacktrace  stacktrace      Man here  https   www boost org doc libs 1 65 1 doc html stacktrace html

User · Answer

You can use the GNU profiler  It shows the call-graph as well  the command is gprof and you need to compile your code with some option

User · Answer

I know this thread is old  but I think it can be useful for other people  If you are using gcc  you can use its instrument features  -finstrument-functions option  to log any function call  entry and exit   Have a look at this for more information  http   hacktalks blogspot fr 2013 08 gcc-instrument-functions html  You can thus for instance push and pop every calls into a stack  and when you want to print it  you just look at what you have in your stack   I ve tested it  it works perfectly and is very handy  UPDATE  you can also find information about the -finstrument-functions compile option in the GCC doc concerning the Instrumentation options  https   gcc gnu org onlinedocs gcc Instrumentation-Options html

User · Answer

Is there any way to dump the call stack in a running process in C or C   every time a certain function is called    No there is not  although platform-dependent solutions might exist

User · Answer

There is no standardized way to do that  For windows the functionality is provided in the DbgHelp library

User · Answer

Is there any way to dump the call stack in a running process in C or C   every time a certain function is called    You can use a macro  function instead of return statement in the specific function   For example  instead of using return   int foo            if  error happened          return -1           do something          return 0     You can use a macro function    include  c-callstack h   int foo            if  error happened          NL RETURN -1            do something          NL RETURN 0       Whenever an error happens in a function  you will see Java-style call stack as shown below   Error code -1  at   so topless ranking server  sample c 23  Error code -1  at   nanolat database  sample c 31  Error code -1  at   nanolat message queue  sample c 39  Error code -1  at   main  sample c 47    Full source code is available here   c-callstack at https   github com Nanolat

User · Answer

You can use Poppy for this  It is normally used to gather the stack trace during a crash but it can also output it for a running program as well    Now here s the good part  it can output the actual parameter values for each function on the stack  and even local variables  loop counters  etc

User · Answer

Linux specific  TLDR    backtrace in glibc produces accurate stacktraces only when -lunwind is linked  undocumented platform-specific feature    To output function name  source file and line number use  include  lt elfutils libdwfl h gt   this library is documented only in its header file   backtrace symbols and backtrace symbolsd fd are least informative      On modern Linux your can get the stacktrace addresses using function backtrace  The undocumented way to make backtrace produce more accurate addresses on popular platforms is to link with -lunwind  libunwind-dev on Ubuntu 18 04   see the example output below   backtrace uses function  Unwind Backtrace and by default the latter comes from libgcc s so 1 and that implementation is most portable  When -lunwind is linked it provides a more accurate version of  Unwind Backtrace but this library is less portable  see supported architectures in libunwind src    Unfortunately  the companion backtrace symbolsd and backtrace symbols fd functions have not been able to resolve the stacktrace addresses to function names with source file name and line number for probably a decade now  see the example output below    However  there is another method to resolve addresses to symbols and it produces the most useful traces with function name  source file and line number  The method is to  include  lt elfutils libdwfl h gt and link with -ldw  libdw-dev on Ubuntu 18 04     Working C   example  test cc     include  lt stdexcept gt   include  lt iostream gt   include  lt cassert gt   include  lt cstdlib gt   include  lt string gt    include  lt boost core demangle hpp gt    include  lt execinfo h gt   include  lt elfutils libdwfl h gt   struct DebugInfoSession       Dwfl Callbacks callbacks           char  debuginfo path   nullptr      Dwfl  dwfl   nullptr       DebugInfoSession             callbacks find elf   dwfl linux proc find elf          callbacks find debuginfo   dwfl standard find debuginfo          callbacks debuginfo path    amp debuginfo path           dwfl   dwfl begin  amp callbacks           assert dwfl            int r          r   dwfl linux proc report dwfl  getpid             assert  r           r   dwfl report end dwfl  nullptr  nullptr           assert  r           static cast lt void gt  r               DebugInfoSession             dwfl end dwfl              DebugInfoSession DebugInfoSession const amp     delete      DebugInfoSession amp  operator  DebugInfoSession const amp     delete      struct DebugInfo       void  ip      std  string function      char const  file      int line       DebugInfo DebugInfoSession const amp  dis  void  ip            ip ip            file             line -1                   Get function name          uintptr t ip2   reinterpret cast lt uintptr t gt  ip           Dwfl Module  module   dwfl addrmodule dis dwfl  ip2           char const  name   dwfl module addrname module  ip2           function   name   boost  core  demangle name      lt unknown gt                Get source filename and line number          if Dwfl Line  dwfl line   dwfl module getsrc module  ip2                 Dwarf Addr addr              file   dwfl lineinfo dwfl line   amp addr   amp line  nullptr  nullptr  nullptr                       std  ostream amp  operator lt  lt  std  ostream amp  s  DebugInfo const amp  di        s  lt  lt  di ip  lt  lt       lt  lt  di function      if di file          s  lt  lt    at    lt  lt  di file  lt  lt       lt  lt  di line      return s     void terminate with stacktrace         void  stack 512       int stack size     backtrace stack  sizeof stack   sizeof  stack           Print the exception info  if any      if auto ex   std  current exception              try               std  rethrow exception ex                     catch std  exception amp  e                std  cerr  lt  lt   Fatal exception    lt  lt  boost  core  demangle typeid e  name     lt  lt        lt  lt  e what    lt  lt     n                     catch                    std  cerr  lt  lt   Fatal unknown exception  n                        DebugInfoSession dis      std  cerr  lt  lt   Stacktrace of    lt  lt  stack size  lt  lt    frames  n       for int i   0  i  lt  stack size    i            std  cerr  lt  lt  i  lt  lt        lt  lt  DebugInfo dis  stack i    lt  lt    n             std  cerr flush         std   Exit EXIT FAILURE      int main         std  set terminate terminate with stacktrace       throw std  runtime error  test exception        Compiled on Ubuntu 18 04 4 LTS with gcc-8 3   g   -o test o -c -m arch tune  native -std gnu  17 -W all extra error  -g -Og -fstack-protector-all test cc g   -o test -g test o -ldw -lunwind   Outputs   Fatal exception std  runtime error  test exception  Stacktrace of 7 frames  0  0x55f3837c1a8c terminate with stacktrace   at  home max src test test cc 76 1  0x7fbc1c845ae5  lt unknown gt  2  0x7fbc1c845b20 std  terminate   3  0x7fbc1c845d53   cxa throw 4  0x55f3837c1a43 main at  home max src test test cc 103 5  0x7fbc1c3e3b96   libc start main at    csu libc-start c 310 6  0x55f3837c17e9  start   When no -lunwind is linked  it produces a less accurate stacktrace   0  0x5591dd9d1a4d terminate with stacktrace   at  home max src test test cc 76 1  0x7f3c18ad6ae6  lt unknown gt  2  0x7f3c18ad6b21  lt unknown gt  3  0x7f3c18ad6d54  lt unknown gt  4  0x5591dd9d1a04 main at  home max src test test cc 103 5  0x7f3c1845cb97   libc start main at    csu libc-start c 344 6  0x5591dd9d17aa  start   For comparison  backtrace symbols fd output for the same stacktrace is least informative    home max src test debug gcc test  0x192f  0x5601c5a2092f   usr lib x86 64-linux-gnu libstdc   so 6  0x92ae5  0x7f95184f5ae5   usr lib x86 64-linux-gnu libstdc   so 6  ZSt9terminatev 0x10  0x7f95184f5b20   usr lib x86 64-linux-gnu libstdc   so 6   cxa throw 0x43  0x7f95184f5d53   home max src test debug gcc test  0x1ae7  0x5601c5a20ae7   lib x86 64-linux-gnu libc so 6   libc start main 0xe6  0x7f9518093b96   home max src test debug gcc test  0x1849  0x5601c5a20849    In a production version  as well as C language version  you may like to make this code extra robust by replacing boost  core  demangle  std  string and std  cout with their underlying calls    You can also override   cxa throw to capture the stacktrace when an exception is thrown and print it when the exception is caught  By the time it enters catch block the stack has been unwound  so it is too late to call backtrace  and this is why the stack must be captured on throw which is implemented by function   cxa throw  Note that in a multi-threaded program   cxa throw can be called simultaneously by multiple threads  so that if it captures the stacktrace into a global array that must be thread local

User · Answer

Boost stacktrace  Documented at  https   www boost org doc libs 1 66 0 doc html stacktrace getting started html stacktrace getting started how to print current call stack  This is the most convenient option I ve seen so far  because it    can actually print out the line numbers   It just makes calls to addr2line however  which is ugly and might be slow if your are taking too many traces  demangles by default Boost is header only  so no need to modify your build system most likely   boost stacktrace cpp   include  lt iostream gt    define BOOST STACKTRACE USE ADDR2LINE  include  lt boost stacktrace hpp gt   void my func 2 void        std  cout  lt  lt  boost  stacktrace  stacktrace    lt  lt  std  endl     void my func 1 double f         void f      my func 2       void my func 1 int i         void i      my func 2       int main int argc  char   argv        long long unsigned int n      if  argc  gt  1            n   strtoul argv 1   NULL  0         else           n   1            for  long long unsigned int i   0  i  lt  n    i            my func 1 1        line 28         my func 1 2 0      line 29           Unfortunately  it seems to be a more recent addition  and the package libboost-stacktrace-dev is not present in Ubuntu 16 04  only 18 04   sudo apt-get install libboost-stacktrace-dev g   -fno-pie -ggdb3 -O0 -no-pie -o boost stacktrace out -std c  11     -Wall -Wextra -pedantic-errors boost stacktrace cpp -ldl   boost stacktrace out   We have to add -ldl at the end or else compilation fails   Output    0  boost  stacktrace  basic stacktrace lt std  allocator lt boost  stacktrace  frame gt   gt   basic stacktrace   at  usr include boost stacktrace stacktrace hpp 129  1  my func 1 int  at  home ciro test boost stacktrace cpp 18  2  main at  home ciro test boost stacktrace cpp 29  discriminator 2   3    libc start main in  lib x86 64-linux-gnu libc so 6  4   start in   boost stacktrace out   0  boost  stacktrace  basic stacktrace lt std  allocator lt boost  stacktrace  frame gt   gt   basic stacktrace   at  usr include boost stacktrace stacktrace hpp 129  1  my func 1 double  at  home ciro test boost stacktrace cpp 13  2  main at  home ciro test boost stacktrace cpp 27  discriminator 2   3    libc start main in  lib x86 64-linux-gnu libc so 6  4   start in   boost stacktrace out   The output and is further explained on the  glibc backtrace  section below  which is analogous   Note how my func 1 int  and my func 1 float   which are mangled due to function overload  were nicely demangled for us   Note that the first int calls is off by one line  28 instead of 27 and the second one is off by two lines  27 instead of 29   It was suggested in the comments that this is because the following instruction address is being considered  which makes 27 become 28  and 29 jump off the loop and become 27   We then observe that with -O3  the output is completely mutilated    0  boost  stacktrace  basic stacktrace lt std  allocator lt boost  stacktrace  frame gt   gt   size   const at  usr include boost stacktrace stacktrace hpp 215  1  my func 1 double  at  home ciro test boost stacktrace cpp 12  2    libc start main in  lib x86 64-linux-gnu libc so 6  3   start in   boost stacktrace out   0  boost  stacktrace  basic stacktrace lt std  allocator lt boost  stacktrace  frame gt   gt   size   const at  usr include boost stacktrace stacktrace hpp 215  1  main at  home ciro test boost stacktrace cpp 31  2    libc start main in  lib x86 64-linux-gnu libc so 6  3   start in   boost stacktrace out   Backtraces are in general irreparably mutilated by optimizations  Tail call optimization is a notable example of that  What is tail call optimization   Benchmark run on -O3   time    boost stacktrace out 1000  gt  dev null   Output   real    0m43 573s user    0m30 799s sys     0m13 665s   So as expected  we see that this method is extremely slow likely to to external calls to addr2line  and is only going to be feasible if a limited number of calls are being made   Each backtrace print seems to take hundreds of milliseconds  so be warned that if a backtrace happens very often  program performance will suffer significantly   Tested on Ubuntu 19 10  GCC 9 2 1  boost 1 67 0   glibc backtrace  Documented at  https   www gnu org software libc manual html node Backtraces html  main c   include  lt stdio h gt   include  lt stdlib h gt      Paste this on the file you want to debug      include  lt stdio h gt   include  lt execinfo h gt  void print trace void        char   strings      size t i  size      enum Constexpr   MAX SIZE   1024        void  array MAX SIZE       size   backtrace array  MAX SIZE       strings   backtrace symbols array  size       for  i   0  i  lt  size  i            printf   s n   strings i        puts          free strings      void my func 3 void        print trace       void my func 2 void        my func 3       void my func 1 void        my func 3       int main void        my func 1       line 33        my func 2       line 34        return 0      Compile   gcc -fno-pie -ggdb3 -O3 -no-pie -o main out -rdynamic -std c99     -Wall -Wextra -pedantic-errors main c   -rdynamic is the key required option   Run     main out   Outputs     main out print trace 0x2d   0x400a3d    main out main 0x9   0x4008f9   lib x86 64-linux-gnu libc so 6   libc start main 0xf0   0x7f35a5aad830    main out  start 0x29   0x400939     main out print trace 0x2d   0x400a3d    main out main 0xe   0x4008fe   lib x86 64-linux-gnu libc so 6   libc start main 0xf0   0x7f35a5aad830    main out  start 0x29   0x400939    So we immediately see that an inlining optimization happened  and some functions were lost from the trace   If we try to get the addresses   addr2line -e main out 0x4008f9 0x4008fe   we obtain    home ciro main c 21  home ciro main c 36   which is completely off   If we do the same with -O0 instead    main out gives the correct full trace     main out print trace 0x2e   0x4009a4    main out my func 3 0x9   0x400a50    main out my func 1 0x9   0x400a68    main out main 0x9   0x400a74   lib x86 64-linux-gnu libc so 6   libc start main 0xf0   0x7f4711677830    main out  start 0x29   0x4008a9     main out print trace 0x2e   0x4009a4    main out my func 3 0x9   0x400a50    main out my func 2 0x9   0x400a5c    main out main 0xe   0x400a79   lib x86 64-linux-gnu libc so 6   libc start main 0xf0   0x7f4711677830    main out  start 0x29   0x4008a9    and then   addr2line -e main out 0x400a74 0x400a79   gives    home cirsan01 test main c 34  home cirsan01 test main c 35   so the lines are off by just one  TODO why  But this might still be usable   Conclusion  backtraces can only possibly show perfectly with -O0  With optimizations  the original backtrace is fundamentally modified in the compiled code   I couldn t find a simple way to automatically demangle C   symbols with this however  here are some hacks    https   panthema net 2008 0901-stacktrace-demangled  https   gist github com fmela 591333 c64f4eb86037bb237862a8283df70cdfc25f01d3   Tested on Ubuntu 16 04  GCC 6 4 0  libc 2 23   glibc backtrace symbols fd  This helper is a bit more convenient than backtrace symbols  and produces basically identical output      Paste this on the file you want to debug      include  lt execinfo h gt   include  lt stdio h gt   include  lt unistd h gt  void print trace void        size t i  size      enum Constexpr   MAX SIZE   1024        void  array MAX SIZE       size   backtrace array  MAX SIZE       backtrace symbols fd array  size  STDOUT FILENO       puts          Tested on Ubuntu 16 04  GCC 6 4 0  libc 2 23   glibc backtrace with C   demangling hack 1  -export-dynamic   dladdr  Adapted from  https   gist github com fmela 591333 c64f4eb86037bb237862a8283df70cdfc25f01d3  This is a  hack  because it requires changing the ELF with -export-dynamic   glibc ldl cpp   include  lt dlfcn h gt         for dladdr  include  lt cxxabi h gt        for   cxa demangle   include  lt cstdio gt   include  lt string gt   include  lt sstream gt   include  lt iostream gt      This function produces a stack backtrace with demangled function  amp  method names  std  string backtrace int skip   1        void  callstack 128       const int nMaxFrames   sizeof callstack    sizeof callstack 0        char buf 1024       int nFrames   backtrace callstack  nMaxFrames       char   symbols   backtrace symbols callstack  nFrames        std  ostringstream trace buf      for  int i   skip  i  lt  nFrames  i              Dl info info          if  dladdr callstack i    amp info                 char  demangled   NULL              int status              demangled   abi    cxa demangle info dli sname  NULL  0   amp status               std  snprintf                  buf                  sizeof buf                     -3d   p  s    zd n                   i                   int  2   sizeof void     2                   callstack i                   status    0   demangled   info dli sname                   char   callstack i  -  char   info dli saddr                            free demangled             else               std  snprintf buf  sizeof buf     -3d   p n                   i   int  2   sizeof void     2   callstack i                      trace buf  lt  lt  buf          std  snprintf buf  sizeof buf     s n   symbols i            trace buf  lt  lt  buf            free symbols       if  nFrames    nMaxFrames          trace buf  lt  lt    truncated  n       return trace buf str       void my func 2 void        std  cout  lt  lt  backtrace    lt  lt  std  endl     void my func 1 double f         void f      my func 2       void my func 1 int i         void i      my func 2       int main         my func 1 1       my func 1 2 0       Compile and run   g   -fno-pie -ggdb3 -O0 -no-pie -o glibc ldl out -std c  11 -Wall -Wextra     -pedantic-errors -fpic glibc ldl cpp -export-dynamic -ldl   glibc ldl out    output   1             0x40130a my func 2     41   glibc ldl out  Z9my func 2v 0x29   0x40130a  2             0x40139e my func 1 int    16   glibc ldl out  Z9my func 1i 0x10   0x40139e  3             0x4013b3 main   18   glibc ldl out main 0x12   0x4013b3  4       0x7f7594552b97   libc start main   231  lib x86 64-linux-gnu libc so 6   libc start main 0xe7   0x7f7594552b97  5             0x400f3a  start   42   glibc ldl out  start 0x2a   0x400f3a   1             0x40130a my func 2     41   glibc ldl out  Z9my func 2v 0x29   0x40130a  2             0x40138b my func 1 double    18   glibc ldl out  Z9my func 1d 0x12   0x40138b  3             0x4013c8 main   39   glibc ldl out main 0x27   0x4013c8  4       0x7f7594552b97   libc start main   231  lib x86 64-linux-gnu libc so 6   libc start main 0xe7   0x7f7594552b97  5             0x400f3a  start   42   glibc ldl out  start 0x2a   0x400f3a    Tested on Ubuntu 18 04   glibc backtrace with C   demangling hack 2  parse backtrace output  Shown at  https   panthema net 2008 0901-stacktrace-demangled   This is a hack because it requires parsing   TODO get it to compile and show it here   libunwind  TODO does this have any advantage over glibc backtrace  Very similar output  also requires modifying the build command  but not part of glibc so requires an extra package installation   Code adapted from  https   eli thegreenplace net 2015 programmatic-access-to-the-call-stack-in-c   main c     This must be on top      define  XOPEN SOURCE 700   include  lt stdio h gt   include  lt stdlib h gt      Paste this on the file you want to debug      define UNW LOCAL ONLY  include  lt libunwind h gt   include  lt stdio h gt  void print trace         char sym 256       unw context t context      unw cursor t cursor      unw getcontext  amp context       unw init local  amp cursor   amp context       while  unw step  amp cursor   gt  0            unw word t offset  pc          unw get reg  amp cursor  UNW REG IP   amp pc           if  pc    0                break                    printf  0x lx    pc           if  unw get proc name  amp cursor  sym  sizeof sym    amp offset     0                printf     s 0x lx  n   sym  offset             else               printf   -- error  unable to obtain symbol name for this frame n                        puts         void my func 3 void        print trace       void my func 2 void        my func 3       void my func 1 void        my func 3       int main void        my func 1       line 46        my func 2       line 47        return 0      Compile and run   sudo apt-get install libunwind-dev gcc -fno-pie -ggdb3 -O3 -no-pie -o main out -std c99     -Wall -Wextra -pedantic-errors main c -lunwind   Either  define  XOPEN SOURCE 700 must be on top  or we must use -std gnu99    Is the type  stack t  no longer defined on linux  Glibc - error in ucontext h  but only with -std c11   Run     main out   Output   0x4007db   main 0xb  0x7f4ff50aa830     libc start main 0xf0  0x400819    start 0x29   0x4007e2   main 0x12  0x7f4ff50aa830     libc start main 0xf0  0x400819    start 0x29    and   addr2line -e main out 0x4007db 0x4007e2   gives    home ciro main c 34  home ciro main c 49   With -O0   0x4009cf   my func 3 0xe  0x4009e7   my func 1 0x9  0x4009f3   main 0x9  0x7f7b84ad7830     libc start main 0xf0  0x4007d9    start 0x29   0x4009cf   my func 3 0xe  0x4009db   my func 2 0x9  0x4009f8   main 0xe  0x7f7b84ad7830     libc start main 0xf0  0x4007d9    start 0x29    and   addr2line -e main out 0x4009f3 0x4009f8   gives    home ciro main c 47  home ciro main c 48   Tested on Ubuntu 16 04  GCC 6 4 0  libunwind 1 1   libunwind with C   name demangling  Code adapted from  https   eli thegreenplace net 2015 programmatic-access-to-the-call-stack-in-c   unwind cpp   define UNW LOCAL ONLY  include  lt cxxabi h gt   include  lt libunwind h gt   include  lt cstdio gt   include  lt cstdlib gt   include  lt iostream gt   void backtrace       unw cursor t cursor    unw context t context        Initialize cursor to current frame for local unwinding    unw getcontext  amp context     unw init local  amp cursor   amp context         Unwind frames one by one  going up the frame stack    while  unw step  amp cursor   gt  0        unw word t offset  pc      unw get reg  amp cursor  UNW REG IP   amp pc       if  pc    0          break            std  printf  0x lx    pc        char sym 256       if  unw get proc name  amp cursor  sym  sizeof sym    amp offset     0          char  nameptr   sym        int status        char  demangled   abi    cxa demangle sym  nullptr  nullptr   amp status         if  status    0            nameptr   demangled                std  printf     s 0x lx  n   nameptr  offset         std  free demangled         else         std  printf   -- error  unable to obtain symbol name for this frame n                 void my func 2 void        backtrace        std  cout  lt  lt  std  endl     line 43    void my func 1 double f         void f      my func 2       void my func 1 int i         void i      my func 2          line 54  int main         my func 1 1       my func 1 2 0       Compile and run   sudo apt-get install libunwind-dev g   -fno-pie -ggdb3 -O0 -no-pie -o unwind out -std c  11     -Wall -Wextra -pedantic-errors unwind cpp -lunwind -pthread   unwind out   Output   0x400c80   my func 2   0x9  0x400cb7   my func 1 int  0x10  0x400ccc   main 0x12  0x7f4c68926b97     libc start main 0xe7  0x400a3a    start 0x2a   0x400c80   my func 2   0x9  0x400ca4   my func 1 double  0x12  0x400ce1   main 0x27  0x7f4c68926b97     libc start main 0xe7  0x400a3a    start 0x2a    and then we can find the lines of my func 2 and my func 1 int  with   addr2line -e unwind out 0x400c80 0x400cb7   which gives    home ciro test unwind cpp 43  home ciro test unwind cpp 54   TODO  why are the lines off by one   Tested on Ubuntu 18 04  GCC 7 4 0  libunwind 1 2 1   GDB automation  We can also do this with GDB without recompiling by using  How to do an specific action when a certain breakpoint is hit in GDB   Although if you are going to print the backtrace a lot  this will likely be less fast than the other options  but maybe we can reach native speeds with compile code  but I m lazy to test it out now  How to call assembly in gdb   main cpp  void my func 2 void      void my func 1 double f        my func 2       void my func 1 int i        my func 2       int main         my func 1 1       my func 1 2 0       main gdb  start break my func 2 commands   silent   backtrace   printf   n    continue end continue   Compile and run   g   -ggdb3 -o main out main cpp gdb -nh -batch -x main gdb main out   Output   Temporary breakpoint 1 at 0x1158  file main cpp  line 12   Temporary breakpoint 1  main    at main cpp 12 12          my func 1 1   Breakpoint 2 at 0x555555555129  file main cpp  line 1   0  my func 2    at main cpp 1  1  0x0000555555555151 in my func 1  i 1  at main cpp 8  2  0x0000555555555162 in main    at main cpp 12   0  my func 2    at main cpp 1  1  0x000055555555513e in my func 1  f 2  at main cpp 4  2  0x000055555555516f in main    at main cpp 13   Inferior 1  process 14193  exited normally    TODO I wanted to do this with just -ex from the command line to not have to create main gdb but I couldn t get the commands to work there   Tested in Ubuntu 19 04  GDB 8 2   Linux kernel  How to print the current thread stack trace inside the Linux kernel   libdwfl  This was originally mentioned at  https   stackoverflow com a 60713161 895245 and it might be the best method  but I have to benchmark a bit more  but please go upvote that answer   TODO  I tried to minimize the code in that answer  which was working  to a single function  but it is segfaulting  let me know if anyone can find why   dwfl cpp   include  lt cassert gt   include  lt iostream gt   include  lt memory gt   include  lt sstream gt   include  lt string gt    include  lt cxxabi h gt       cxa demangle  include  lt elfutils libdwfl h gt     Dwfl   include  lt execinfo h gt     backtrace  include  lt unistd h gt     getpid     https   stackoverflow com questions 281818 unmangling-the-result-of-stdtype-infoname std  string demangle const char  name        int status   -4      std  unique ptr lt char  void    void   gt  res           abi    cxa demangle name  NULL  NULL   amp status           std  free            return  status  0    res get     name      std  string debug info Dwfl  dwfl  void  ip        std  string function      int line   -1      char const  file      uintptr t ip2   reinterpret cast lt uintptr t gt  ip       Dwfl Module  module   dwfl addrmodule dwfl  ip2       char const  name   dwfl module addrname module  ip2       function   name   demangle name      lt unknown gt        if  Dwfl Line  dwfl line   dwfl module getsrc module  ip2             Dwarf Addr addr          file   dwfl lineinfo dwfl line   amp addr   amp line  nullptr  nullptr  nullptr             std  stringstream ss      ss  lt  lt  ip  lt  lt       lt  lt  function      if  file          ss  lt  lt    at    lt  lt  file  lt  lt       lt  lt  line      ss  lt  lt  std  endl      return ss str       std  string stacktrace            Initialize Dwfl      Dwfl  dwfl   nullptr                Dwfl Callbacks callbacks               char  debuginfo path   nullptr          callbacks find elf   dwfl linux proc find elf          callbacks find debuginfo   dwfl standard find debuginfo          callbacks debuginfo path    amp debuginfo path          dwfl   dwfl begin  amp callbacks           assert dwfl           int r          r   dwfl linux proc report dwfl  getpid             assert  r           r   dwfl report end dwfl  nullptr  nullptr           assert  r           static cast lt void gt  r                 Loop over stack frames      std  stringstream ss                void  stack 512           int stack size     backtrace stack  sizeof stack   sizeof  stack           for  int i   0  i  lt  stack size    i                ss  lt  lt  i  lt  lt                        Works              ss  lt  lt  debug info dwfl  stack i      if 0                TODO intended to do the same as above  but segfaults                 so possibly UB In above function that does not blow up by chance              void  ip   stack i               std  string function              int line   -1              char const  file              uintptr t ip2   reinterpret cast lt uintptr t gt  ip               Dwfl Module  module   dwfl addrmodule dwfl  ip2               char const  name   dwfl module addrname module  ip2               function   name   demangle name      lt unknown gt                   TODO if I comment out this line it does not blow up anymore              if  Dwfl Line  dwfl line   dwfl module getsrc module  ip2                   Dwarf Addr addr                file   dwfl lineinfo dwfl line   amp addr   amp line  nullptr  nullptr  nullptr                             ss  lt  lt  ip  lt  lt       lt  lt  function              if  file                  ss  lt  lt    at    lt  lt  file  lt  lt       lt  lt  line              ss  lt  lt  std  endl   endif                     dwfl end dwfl       return ss str       void my func 2         std  cout  lt  lt  stacktrace    lt  lt  std  endl      std  cout flush       void my func 1 double f         void f      my func 2       void my func 1 int i         void i      my func 2       int main int argc  char   argv        long long unsigned int n      if  argc  gt  1            n   strtoul argv 1   NULL  0         else           n   1            for  long long unsigned int i   0  i  lt  n    i            my func 1 1           my func 1 2 0             Compile and run   sudo apt install libdw-dev g   -fno-pie -ggdb3 -O0 -no-pie -o dwfl out -std c  11 -Wall -Wextra -pedantic-errors dwfl cpp -ldw   dwfl out   Output   0  0x402b74 stacktrace abi cxx11    at  home ciro test dwfl cpp 65 1  0x402ce0 my func 2   at  home ciro test dwfl cpp 100 2  0x402d7d my func 1 int  at  home ciro test dwfl cpp 112 3  0x402de0 main at  home ciro test dwfl cpp 123 4  0x7f7efabbe1e3   libc start main at    csu libc-start c 342 5  0x40253e  start at    csu libc-start c -1  0  0x402b74 stacktrace abi cxx11    at  home ciro test dwfl cpp 65 1  0x402ce0 my func 2   at  home ciro test dwfl cpp 100 2  0x402d66 my func 1 double  at  home ciro test dwfl cpp 107 3  0x402df1 main at  home ciro test dwfl cpp 121 4  0x7f7efabbe1e3   libc start main at    csu libc-start c 342 5  0x40253e  start at    csu libc-start c -1    Benchmark run   g   -fno-pie -ggdb3 -O3 -no-pie -o dwfl out -std c  11 -Wall -Wextra -pedantic-errors dwfl cpp -ldw time   dwfl out 1000  gt  dev null   Output   real    0m3 751s user    0m2 822s sys     0m0 928s   So we see that this method is 10x faster than Boost s stacktrace  and might therefore be applicable to more use cases    Tested in Ubuntu 19 10 amd64  libdw-dev 0 176-1 1   See also   How can one grab a stack trace in C  How to make backtrace   backtrace symbols   print the function names  Is there a portable standard-compliant way to get filenames and linenumbers in a stack trace  Best way to invoke gdb from inside program to print its stacktrace  automatic stack trace on failure    on C   exception  C   display stack trace on exception generic  How to automatically generate a stacktrace when my program crashes

[c++] print call stack in C or C++

Examples related to c++

Examples related to c

Examples related to linux

Examples related to callstack