Re: gdb not recognizing core file format
> I'm trying to use gdb to get a stack trace on a program
> that is dumping core without success.
...
> warning: "/home/reif/flt/core": no core file handler recognizes format,
> using default
> Core was generated by `./test ../testfiles/0.flt'.
> Program terminated with signal 11, Segmentation fault.
> Couldn't read input and local registers from core file
> Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
> Loaded symbols for /usr/lib/libstdc++-libc6.2-2.so.3
> Reading symbols from /lib/libm.so.6...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> Couldn't read input and local registers from core file
> #0 0x00000004 in ?? ()
> (gdb) bt
> #0 0x00000004 in ?? ()
> Cannot access memory at address 0x3b
> (gdb) quit
It seems it conforms to a corefile format close enough so
you get the command name and run time args, but the
registers etc and stack are messed up. I've never seen
registers messed up, but I've seen a messed up stack when I
write past the end of local variables (and thereby mess up
the stack frame).
Try using the debugger to run the program from the beginning
and when it crashes, try a back trace. You'll probably get
a similar backtrace (ie, unusable). The point of this
step is that you might get lucky and the bt would be
readable.
Now it's time to do some detective slogging: put a
breakpoint near the beginning of the program, run it: if it
stops neatly at the breakpoint, the crash occurs after.
Move the breakpoint later and try again. Find the crash
point that way.
Look at variables just before the crash, try to see if
anything is wrong... etc etc. With signal 11, you're
looking for attempts to dereference null pointers or other
addresses that are not accessible to your program.
HTH
--
bjb@achilles.net
Welcome to the GNU age! http://www.gnu.org
Reply to: