tags:

views:

226

answers:

2

I use GDB to debug C/C++ programs very often, and I'm reasonably knowledgeable with how it works and what it can do.

However, every so often I run into problems where mysteriously I can't seem to get GDB to properly load symbols from a core file.

Currently, I have a binary executable in a shared NFS directory. The executable was definitely compiled with the -g3 flag. The executable crashed and dumped a core file into the /home directory of my Linux box.

For some reason, I can't get GDB to load the symbols from the core file.

When I try:

$ gdb <executable_file> <core_file>

GDB loads up, but I can't get a backtrace, and no debugging symbols are loaded.

If I run GDB, and then at the GDB prompt I type core <core file name> it loads up the core file, and I see that the core file is definitely associated with the binary executable that crashed earlier. However, GDB reports `Failed to read a valid object file image from memory', so I can't get a meaningful back-trace, and there are no debugging symbols loaded.

Does anyone know what might be the cause of this? Usually I have no trouble getting GDB to properly load up a core file and read in debugging symbols, but in this case it doesn't work. Could it be because the binary executable is stored on a shared NFS mount?

+1  A: 

Check your ulimits. It's quite a common source of confusion. Truncated core files can make any form of gdb inspection useless, well you can read the name of the binary in most cases, and if the core file is at least 8k you can get a stack trace.

hroptatyr
A: 

are all the shared libraries getting loaded? try

 $ ldd <executable_file> 
and see if that helps you figure things out.

vineet