How to get a stack trace for C++ using gcc with line number information? [duplicate]

Asked 8/1, 2011 at 22:15 Answered 23/11, 2022 at 16:35

We use stack traces in proprietary assert like macro to catch developer mistakes - when error is caught, stack trace is printed.

I find gcc's pair backtrace()/backtrace_symbols() methods insufficient:

Names are mangled
No line information

1st problem can be resolved by abi::__cxa_demangle.

However 2nd problem s more tough. I found replacement for backtrace_symbols(). This is better than gcc's backtrace_symbols(), since it can retrieve line numbers (if compiled with -g) and you don't need to compile with -rdynamic.

Hoverer the code is GNU licenced, so IMHO I can't use it in commercial code.

Any proposal?

P.S.

gdb is capable to print out arguments passed to functions. Probably it's already too much to ask for :)

PS 2

Similar question (thanks nobar)

Misshapen answered 8/1, 2011 at 22:15 Comment(4)

Either find the author and pay him or reimplement it yourself. – Lemures 8/1, 2011 at 22:23

I'm not sure if using compiled GNU code on your commercial application is the same as modifying/customize the GNU code itself to distribute inside your app. Anyone? – Scone 12/1, 2011 at 22:15

Is it for Linux/x86 only or you should this code run on different platforms? – Buskined 13/1, 2011 at 13:48

No line number requirement: https://mcmap.net/q/64721/-how-to-print-a-stack-trace-whenever-a-certain-function-is-called – Acquit 2/7, 2015 at 18:39

Not too long ago I answered a similar question. You should take a look at the source code available on method #4, which also prints line numbers and filenames.

Method #4:

A small improvement I've done on method #3 to print line numbers. This could be copied to work on method #2 also.

Basically, it uses addr2line to convert addresses into file names and line numbers.

The source code below prints line numbers for all local functions. If a function from another library is called, you might see a couple of ??:0 instead of file names.

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

void bt_sighandler(int sig, struct sigcontext ctx) {

  void *trace[16];
  char **messages = (char **)NULL;
  int i, trace_size = 0;

  if (sig == SIGSEGV)
    printf("Got signal %d, faulty address is %p, "
           "from %p\n", sig, ctx.cr2, ctx.eip);
  else
    printf("Got signal %d\n", sig);

  trace_size = backtrace(trace, 16);
  /* overwrite sigaction with caller's address */
  trace[1] = (void *)ctx.eip;
  messages = backtrace_symbols(trace, trace_size);
  /* skip first stack frame (points here) */
  printf("[bt] Execution path:\n");
  for (i=1; i<trace_size; ++i)
  {
    printf("[bt] #%d %s\n", i, messages[i]);

    /* find first occurence of '(' or ' ' in message[i] and assume
     * everything before that is the file name. (Don't go beyond 0 though
     * (string terminator)*/
    size_t p = 0;
    while(messages[i][p] != '(' && messages[i][p] != ' '
            && messages[i][p] != 0)
        ++p;

    char syscom[256];
    sprintf(syscom,"addr2line %p -e %.*s", trace[i], p, messages[i]);
        //last parameter is the file name of the symbol
    system(syscom);
  }

  exit(0);
}


int func_a(int a, char b) {

  char *p = (char *)0xdeadbeef;

  a = a + b;
  *p = 10;  /* CRASH here!! */

  return 2*a;
}


int func_b() {

  int res, a = 5;

  res = 5 + func_a(a, 't');

  return res;
}


int main() {

  /* Install our signal handler */
  struct sigaction sa;

  sa.sa_handler = (void *)bt_sighandler;
  sigemptyset(&sa.sa_mask);
  sa.sa_flags = SA_RESTART;

  sigaction(SIGSEGV, &sa, NULL);
  sigaction(SIGUSR1, &sa, NULL);
  /* ... add any other signal here */

  /* Do something */
  printf("%d\n", func_b());
}

This code should be compiled as: gcc sighandler.c -o sighandler -rdynamic

The program outputs:

Got signal 11, faulty address is 0xdeadbeef, from 0x8048975
[bt] Execution path:
[bt] #1 ./sighandler(func_a+0x1d) [0x8048975]
/home/karl/workspace/stacktrace/sighandler.c:44
[bt] #2 ./sighandler(func_b+0x20) [0x804899f]
/home/karl/workspace/stacktrace/sighandler.c:54
[bt] #3 ./sighandler(main+0x6c) [0x8048a16]
/home/karl/workspace/stacktrace/sighandler.c:74
[bt] #4 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x3fdbd6]
??:0
[bt] #5 ./sighandler() [0x8048781]
??:0

Scone answered 12/1, 2011 at 22:5 Comment(12)

Remember to compile your application with -rdynamic. – Scone 12/1, 2011 at 22:16

@karlphillip, about GPL. if the GPL (not GNU, but GPL-licensed) code is linked (with ld.so or ld) into another code, the GPL require that another code is available under GPL. This all is only true in case when the application is transfered to another people. Personally you can do anything with GPL code and link it with anything. – Buskined 12/1, 2011 at 22:26

@Buskined And what happens if your app uses dynamically linked GPL libraries available on the system target. Same rule? – Scone 12/1, 2011 at 22:29

For the many dynamic libraries there is a LGPL license, which allows linking. – Buskined 12/1, 2011 at 22:32

I accept the answer, since the answer is most close for what I want. – Misshapen 19/1, 2011 at 15:31

@dimba: Don't forget to award him the bounty as well (just underneath the accept tick!!) – Hudspeth 19/1, 2011 at 18:3

@Scone I tried your solution and looked into the linux journal article, however I need to do what is being done in that program without a crash in the program. Basically I am trying to implement a custom exception class which will print the backtrace and line numbers, etc when an exception is caught. So, I do not have a SIGSEGV coming into the picture. Any thoughts on how that might be achieved ? – Vertievertiginous 5/6, 2013 at 14:57

error: ‘struct sigcontext’ has no member named ‘eip’; did you mean ‘rip’? – Zucker 31/3, 2020 at 18:52

@Zucker I fixed the error as suggested by replacing 'eip' with 'rip'. – Survivor 22/6, 2021 at 8:53

I don't think this answer is valid anymore. I've compiled the code (applying eip -> rip fix) on Ubunu 18 and didn't get a single line correct:

Got signal 11, faulty address is 0x10202, from (nil) [bt] Execution path: [bt] #1 [(nil)] sh: 1: Syntax error: word unexpected (expecting ")") [bt] #2 ./sighandler(func_a+0x20) [0x55b0d4f96dad] ??:0 [bt] #3 ./sighandler(func_b+0x1e) [0x55b0d4f96dd5] ??:0 [bt] #4 ./sighandler(main+0x7e) [0x55b0d4f96e5e] ??:0

– Duckweed 29/7, 2021 at 13:58

Run it inside GDB and identify the offending line. – Scone 29/7, 2021 at 23:15

This isn't going to work with aslr. – Hendrick 30/7, 2023 at 12:37

So you want a stand-alone function that prints a stack trace with all of the features that gdb stack traces have and that doesn't terminate your application. The answer is to automate the launch of gdb in a non-interactive mode to perform just the tasks that you want.

This is done by executing gdb in a child process, using fork(), and scripting it to display a stack-trace while your application waits for it to complete. This can be performed without the use of a core-dump and without aborting the application. I learned how to do this from looking at this question: How it's better to invoke gdb from program to print it's stacktrace?

The example posted with that question didn't work for me exactly as written, so here's my "fixed" version (I ran this on Ubuntu 9.04).

#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>
#include <sys/prctl.h>

void print_trace() {
    char pid_buf[30];
    sprintf(pid_buf, "%d", getpid());
    char name_buf[512];
    name_buf[readlink("/proc/self/exe", name_buf, 511)]=0;
    prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);
    int child_pid = fork();
    if (!child_pid) {
        dup2(2,1); // redirect output to stderr - edit: unnecessary?
        execl("/usr/bin/gdb", "gdb", "--batch", "-n", "-ex", "thread", "-ex", "bt", name_buf, pid_buf, NULL);
        abort(); /* If gdb failed to start */
    } else {
        waitpid(child_pid,NULL,0);
    }
}

As shown in the referenced question, gdb provides additional options that you could use. For example, using "bt full" instead of "bt" produces an even more detailed report (local variables are included in the output). The manpages for gdb are kind of light, but complete documentation is available here.

Since this is based on gdb, the output includes demangled names, line-numbers, function arguments, and optionally even local variables. Also, gdb is thread-aware, so you should be able to extract some thread-specific metadata.

Here's an example of the kind of stack traces that I see with this method.

0x00007f97e1fc2925 in waitpid () from /lib/libc.so.6
[Current thread is 0 (process 15573)]
#0  0x00007f97e1fc2925 in waitpid () from /lib/libc.so.6
#1  0x0000000000400bd5 in print_trace () at ./demo3b.cpp:496
2  0x0000000000400c09 in recursive (i=2) at ./demo3b.cpp:636
3  0x0000000000400c1a in recursive (i=1) at ./demo3b.cpp:646
4  0x0000000000400c1a in recursive (i=0) at ./demo3b.cpp:646
5  0x0000000000400c46 in main (argc=1, argv=0x7fffe3b2b5b8) at ./demo3b.cpp:70

Note: I found this to be incompatible with the use of valgrind (probably due to Valgrind's use of a virtual machine). It also doesn't work when you are running the program inside of a gdb session (can't apply a second instance of "ptrace" to a process).

Smokestack answered 19/1, 2011 at 5:42 Comment(16)

@nobar +1 Good! When it prints the line numbers it would be even better. – Scone 19/1, 2011 at 12:3

It does print the line numbers for me. What makes you say that it doesn't? – Smokestack 19/1, 2011 at 15:2

@nobar The fact that on my system, it doesn't! And I'm compiling with -rdynamic and -g. How are you compiling the test application? I'm using GDB 7.1, how about you? – Scone 19/1, 2011 at 17:18

@karlphillip: I'm only using "-g" to compile. My gdb is version "6.8-debian". The current gdb documentation says that it will print line numbers in a back-trace: "The backtrace also shows the source file name and line number, as well as the arguments to the function." Does your test application work with a debugger (can you single-step through your source lines)? – Smokestack 19/1, 2011 at 17:47

@nobar I apologize, I can see it now: #3 0x080489d5 in main () at stacktrace_test.cpp:29 You should add a reference to this answer at the other question, which hasn't been answered yet. Thank you. – Scone 19/1, 2011 at 17:58

@karlphillip: Great! I edited my answer to include example output. – Smokestack 19/1, 2011 at 18:4

DO NOT USE THIS! I used the above function verbatim in my program, and on Ubuntu 12.04 it completely crashes the X Server. – Close 13/8, 2012 at 7:32

@BeniBela, what kind of program were you running? Was it something low-level? This approach works fine for me in Fedora 17. – Depose 4/12, 2012 at 22:47

I realize this can be repurpose to give you an interactive debugger session to inspect the moribund process, by removing the "--batch". I wonder if there a simple way to use gdb to make the process resume from where it left off, causing the original signal to be rethrown and caught by gdb. – Depose 4/12, 2012 at 22:49

@Syncopated: No, a normal qt desktop application. Perhaps it is caused some kind of input wrapper (like Dbus, or so??) which connects to the original application and the fork, and then blocks the input – Close 4/12, 2012 at 23:25

And it is getting worse: ptracing the parent is now no longer permitted. But perhaps there is a flag you can set with prctl? – Close 14/6, 2013 at 12:41

@BeniBela: Thanks for the pointer. One possible workaround is to run with sudo. – Smokestack 18/6, 2013 at 19:12

You can bypass it with #include <sys/prctl.h> prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0); before fork(). – Westernize 27/4, 2014 at 17:50

execl is safer than execlp and works perfectly, too – Maynard 9/4, 2018 at 15:51

@GiovanniFunchal All, I've updated the answer such that it works again (without prctl() it would not), according to the comments. Thanks! I also removed the fprintf() call because it wasn't outputting anything, and I'm not sure if the dup2() call is needed/helpful either. – Tubular 22/11, 2020 at 20:36

@PatrizioBertoni It does work; I had to change gdb to /usr/bin/gdb to get it to work, as seen in my edit. That was my understanding of what needed to be done from reading the docs, and it works. – Tubular 22/11, 2020 at 20:36