[ACCEPTED]-What does the GDB backtrace message "0x0000000000000000 in ?? ()" mean?-freebsd

Accepted answer
Score: 13

gdb wasn't able to extract the proper return 7 address from pthread_mutexattr_init; it 6 got an address of 0. The "??" is the result 5 of looking up address 0 in the symbol table. It 4 cannot find a symbolic name, so it prints 3 a default "??"

Unfortunately right offhand 2 I don't know why it could not extract the 1 correct return address.

Score: 8

Something you did cause the threading library 9 to crash. Since the threading library itself 8 is not compiled with debugging symbols (-g), it 7 cannot display the source code file or line 6 number the crash happened on. In addition, since 5 it's threads, the call stack does not point 4 back to your file. Unfortunately this will 3 be a tough bug to track down, you're gonna 2 need to step through your code and try and 1 narrow down when exactly the crash happens.

Score: 4

Make sure you compile with debug symbols. (For 5 gcc I think that is the -g option). Then 4 you should be able to get more interesting 3 information out of GDB. Don't forget to 2 turn it off when you compile the production 1 version.

Score: 3

I could be missing something, but isn't 10 this indicative of someone using NULL as a function 9 pointer?

#include <stdio.h>

typedef int (*funcptr)(void);

int
func_caller(funcptr f)
{
    return (*f)();
}

int
main()
{
    return func_caller(NULL);
}

This produces the same style of 8 a backtrace if you run it in gdb:

rivendell$ gcc -g -O0 foo.c -o foo
rivendell$ gdb --quiet foo
Reading symbols for shared libraries .. done
(gdb) r
Starting program: ...
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) bt
#0    0x00000000 in ?? ()
#1    0x00001f9d in func_caller (f=0) at foo.c:8
#2    0x00001fb1 in main () at foo.c:14

This is 7 a pretty strange crash though... pthread_mutexattr_init rarely 6 does anything more than allocate a data 5 structure and memset it. I'd look for something 4 else going on. Is there a possibility of 3 mismatched threading libraries or something. My 2 BSD knowledge is a little dated, but there 1 used to be issues around this.

Score: 1

Maybe the bug that caused the crash has 3 broken the stack (overwritten parts of the 2 stack)? In that case, the backtrace might 1 be useless; no idea what to do in that case...

More Related questions