How to make backtrace()/backtrace_symbols() print the function names?
Asked Answered
S

5

106

The Linux specific backtrace() and backtrace_symbols() allows you to produce a call trace of the program. However, it only prints function addresses, not their names for my program. How can I make them print the function names as well ? I've tried compiling the program with -g as well as -ggdb. The test case below just prints this:


    BACKTRACE ------------
    ./a.out() [0x8048616]
    ./a.out() [0x8048623]
    /lib/libc.so.6(__libc_start_main+0xf3) [0x4a937413]
    ./a.out() [0x8048421]
    ----------------------
    

I'd want the first 2 items to also show the function names, foo and main

Code:

#include <execinfo.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>

static void full_write(int fd, const char *buf, size_t len)
{
        while (len > 0) {
                ssize_t ret = write(fd, buf, len);

                if ((ret == -1) && (errno != EINTR))
                        break;

                buf += (size_t) ret;
                len -= (size_t) ret;
        }
}

void print_backtrace(void)
{
        static const char start[] = "BACKTRACE ------------\n";
        static const char end[] = "----------------------\n";

        void *bt[1024];
        int bt_size;
        char **bt_syms;
        int i;

        bt_size = backtrace(bt, 1024);
        bt_syms = backtrace_symbols(bt, bt_size);
        full_write(STDERR_FILENO, start, strlen(start));
        for (i = 1; i < bt_size; i++) {
                size_t len = strlen(bt_syms[i]);
                full_write(STDERR_FILENO, bt_syms[i], len);
                full_write(STDERR_FILENO, "\n", 1);
        }
        full_write(STDERR_FILENO, end, strlen(end));
    free(bt_syms);
}
void foo()
{
    print_backtrace();
}

int main()
{
    foo();
    return 0;
}
Shrum answered 3/8, 2011 at 23:49 Comment(5)
possible duplicate of How to get more detailed backtraceAllayne
btw, function backtrace_symbols_fd performs the same operation as backtrace_symbols(), but the resulting strings are immediately written to the file descriptor fd.Clarinda
I have tested several methods in detail at: https://mcmap.net/q/64721/-how-to-print-a-stack-trace-whenever-a-certain-function-is-called/…Entryway
Since the second argument of backtrace() specifies the maximum number of addresses that can be stored in the buffer specified by the first (man 3 backtrace), a value of 1024 is unnecessarily generous here. A value of 20 should do fine, and printing a warning for possible truncation when bt_size == 20 is good practice.Subcritical
This is happening with golang 1.21. I solved it by downgrading it to 1.20.8Linesman
T
78

The symbols are taken from the dynamic symbol table; you need the -rdynamic option to gcc, which makes it pass a flag to the linker which ensures that all symbols are placed in the table.

(See the Link Options page of the GCC manual, and / or the Backtraces page of the glibc manual.)

Therefor answered 4/8, 2011 at 0:23 Comment(3)
This doesn't work for static symbols, though. libunwind that @Allayne mentions, works for static functions.Newfeld
In a CMake project, this had mistakenly been set as ADD_COMPILE_OPTIONS(-rdynamic). Instead, it needs to be ADD_LINK_OPTIONS(-rdynamic) or equivalent to have the desired behaviour.Pannier
Better yet for those using cmake: SET (CMAKE_ENABLE_EXPORTS TRUE). This sets the -rdynamic linker flag.Pannier
A
35

Use the addr2line command to map executable addresses to source code filename+line number. Give the -f option to get function names as well.

Alternatively, try libunwind.

Allayne answered 4/8, 2011 at 0:49 Comment(5)
addr2 line is nice because it includes file name and line number in the output, but it fails as soon as relocations are performed by the loader.Popgun
... and with ASLR relocations are more common than ever.Popgun
@ErwanLegrand: Before ASLR, I thought the relocations were predictable and addr2line worked reliably even for addresses in shared objects (?) But yeah, on modern platforms you would need to know the actual load address of the relocatable object even to do this operation in principle.Allayne
I can't tell for sure how well it worked before ASLR. Nowadays, it will only for for code inside "regular" executables and fail for code inside DSOs and PIEs (Position Independent Executables). Fortunately, libunwind appears to work for all of these.Popgun
I had forgotten about this discussion. Libbacktrace, which I did not know of at the time, is a better option. (See my new answer.)Popgun
P
15

The excellent Libbacktrace by Ian Lance Taylor solves this issue. It handles stack unwinding and supports both ordinary ELF symbols and DWARF debugging symbols.

Libbacktrace does not require exporting all symbols, which would be ugly, and ASLR does not break it.

Libbacktrace was originally part of the GCC distribution. Now, a standalone version can be found on Github:

https://github.com/ianlancetaylor/libbacktrace

Popgun answered 27/5, 2015 at 10:9 Comment(0)
E
3

Boost backtrace

Very convenient because it prints both:

  • unmangled C++ function names
  • line numbers

automatically for you.

Usage summary:

#define BOOST_STACKTRACE_USE_ADDR2LINE
#include <boost/stacktrace.hpp>

std::cout << boost::stacktrace::stacktrace() << std::endl;

I have provided a minimal runnable example for it and many other methods at: print call stack in C or C++

Entryway answered 14/10, 2019 at 12:21 Comment(1)
The question is tagged [c], not [c++].Narcho
B
2

the answer on the top has a bug if ret == -1 and errno is EINTER you should try again, but not count ret as copied (not going to make an account just for this, if you don't like it tough)

static void full_write(int fd, const char *buf, size_t len)
{
        while (len > 0) {
                ssize_t ret = write(fd, buf, len);

                if ((ret == -1) {
                        if (errno != EINTR))
                                break;
                        //else
                        continue;
                }
                buf += (size_t) ret;
                len -= (size_t) ret;
        }
}
Bluegreen answered 16/11, 2017 at 18:22 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.