Planning to write a series of posts about debugging & trouble shooting tricks. And I’d like to make backtrace as a start. As a typical programmer(AKA nerd), I’d like to jump to the topic directly before run into blah-blah.

Everyone knows, bug is free, so it may be at everywhere, to check out your free gift(s) sending to your clients, you may consider backtrace.

It’s a great way for trouble shooting. It’ll be terribly useful when your program run into core dump.

And it’s really simple, all you need to do is:
1. Register SIGSEGV and use signal(SIGSEGV, &your_function); to catch the signal.
2. Put the code to the head of your main function.

Here I copied a code snippet for you:

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

void dump(int signo)
{
 void *buffer[30] = {0};
 size_t size;
 char **strings = NULL;
 size_t i = 0;

 size = backtrace(buffer, 30);
 fprintf(stdout, "Obtained %zd stack frames.nm\n", size);
 strings = backtrace_symbols(buffer, size);
 if (strings == NULL)
 {
  perror("backtrace_symbols.");
  exit(EXIT_FAILURE);
 }
 
 for (i = 0; i < size; i++)
 {
  fprintf(stdout, "%s\n", strings[i]);
 }
 free(strings);
 strings = NULL;
 exit(0);
}

void func_c()
{
  //This is the "free gift" you send to your clients
 *((volatile char *)0x0) = 0x9999;
}

void func_b()
{
 func_c();
}

void func_a()
{
 func_b();
}

int main(int argc, const char *argv[])
{
 if (signal(SIGSEGV, dump) == SIG_ERR)
  perror("can't catch SIGSEGV");
 func_a();
 return 0;
}

Save it with filename like backtrace1.c, and compile it with command:
gcc backtrace1.c -o test

gcc -g -rdynamic backtrace1.c -o test

Run the newly compiled program

./test

When your free gift shows up, and caused a segmentation fault(core dump), you’ll see something like this:

=================== call trace ======================
Obtained 7 stack frames.nm
./test(dump+0x45) [0x80487a9]
[0x736400]
./test(func_b+0x8) [0x804886c]
./test(func_a+0x8) [0x8048876]
./test(main+0x33) [0x80488ab]
/lib/libc.so.6(__libc_start_main+0xe6) [0xbbccc6]
./test() [0x80486d1]

Dont panic. Dont you like the lovely address numbers? no? Okay,  a few more steps you’ll get the truth:

1. Use objdump to disassemble the executable file

objdump -d test > test.s

2. Check the assemble codes for the displayed addresss: 0x804886c

08048864 <func_b>:
 8048864:       55                      push   %ebp
 8048865:       89 e5                   mov    %esp,%ebp
 8048867:       e8 eb ff ff ff          call   8048857 <func_c>
 804886c:       5d                      pop    %ebp
 804886d:       c3                      ret

As you can see, the previous step was “call 8048857 <func_c>“, we can make the conclusion that it was <func_c> where went wrong, although address 804886c did not locate direct to the error code.

3.  A more effecial tool than disassembling the objects: addr2line

You can use addr2line to convert it code line.

addr2line 0x804886C -e test -f -C

Truth revealed.