tags:

views:

71

answers:

2

I'd like to know if my program is accessing NULL pointers or stale memory.

The backtrace looks like this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b0fa4c8 (LWP 1333)]
0x299a6ad4 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) bt
#0  0x299a6ad4 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x0058e900 in ?? ()
A: 

Run your program under GDB. When the segfault occurs, GDB will inform you of the line and statement of your program, along with the variable and its associated address.

You can use the "print" (p) command in GDB to inspect variables. If the crash occurred in a library call, you can use the "frame" series of commands to see the stack frame in question.

Yann Ramin
The segfault isn't in code that I have the source to.
nornagon
@nornagon: The `bt` command will show you a backtrace, which will let you see where you were in your own code when the fault happened.
caf
Yes, I know, but it's still no help -- it was in a library function call with several arguments, and I don't know which of those arguments is causing a segfault.
nornagon
put watchs on those which could be wrong; put bp before the place you suspect sigfault could happen, and step instr by instr watching important vars...
ShinTakezou
@nornagon: Your backtrace is suspicious - you probably have stack corruption before calling your arguments. If stepping through the code ("n" and "s") doesn't reveal the problem, it is time to break out valgrind.
Yann Ramin
unfortunately valgrind doesn't work on sh4
nornagon
+2  A: 

With GDB 7 and higher, you can examine the $_siginfo structure that is filled out when the signal occurs, and determine the faulting address:

(gdb) p $_siginfo._sifields._sigfault.si_addr

If it shows (void *) 0x0 (or a small number) then you have a NULL pointer dereference.

caf
(gdb) p $_siginfo$1 = voidI guess siginfo isn't supported on this architecture :(
nornagon