Arch Linux

mallex

Member

Registered: 2020-04-04

Posts: 1

Problem with backtrace output (gcc 9.3.0-1)

I just recently set up a ArchLinux environment and a unit test on some code revealed a bug in the behavior of backtrace/backtrace_symbols

The output is providing addresses that don't make sense (way too big).  They are not able to be processed by addr2line in the way I would have expected.

The sample program demonstrates the problem:

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

int
main(int argc, char *argv[])
{
    void * trace[32];
    char ** messages = NULL;
    int trace_size = 0;

    trace_size = backtrace(trace, 32);
    if (trace_size > 0)
    {
        messages = backtrace_symbols(trace, trace_size);
        for (int i=0; i<trace_size; i++)
        {
            if (i > 0)
                printf("\n");

            if (messages[i] == NULL)
                printf("<unknown>");
            else
                printf("%s", messages[i]);
        }

        free(messages);
    }
    else
        printf("backtrace unavailable");

        return 0;
}

On Arch (gcc version 9.3.0)

./a.out(+0x11d9) [0x558bba65c1d9]
/usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f1f09433023]
./a.out(+0x10be) [0x558bba65c0be]

On CentOS 8 (gcc 8.3.1)

./a.out() [0x400701]
/lib64/libc.so.6(__libc_start_main+0xf3) [0x7fa46b997873]
./a.out() [0x40060e]

When using addr2line to look at the result I get the following:

On Arch

addr2line 0x558bba65c1d9
??:0

On CentOS
addr2line 0x400701
/home/dev/t.c:12

Should this be reported against the Arch bug list or the GCC (glibc) bug list?