GDB is not able to read the core file it produced

user_898480 0
Viewed 511

I'm debugging a SIGSEGV error on a huge application running on Yocto/ARM64 (iMX8QM).

If I run the application in GDB, I can get the backtrace:

Thread 1 "HmiAppCentral" received signal SIGSEGV, Segmentation fault.                                   
0x0000000000b0a0d0 in kanzi::Node3D::~Node3D() ()                                                       
(gdb) bt                                                                                                
#0  0x0000000000b0a0d0 in kanzi::Node3D::~Node3D() ()                                                   
#1  0x0000000000cd4e44 in kanzi::Model3D::~Model3D() ()                                                 
#2  0x0000000000b09c38 in kanzi::Node3D::removeChild(unsigned long) ()
[...]

Then I export the core dump, quit GDB and restart it:

(gdb) generate-core-file                                                                                
warning: target file /proc/2279/cmdline contained unexpected null characters
[...]
gdb -c core.2279

Then GDB is not able to print the backtrace anymore:

(gdb) bt full
#0  0x0000000000b0a0d0 in ?? ()
No symbol table info available.
#1  0x0000000000000001 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The address of the first frame is correct (0x0000000000b0a0d0), however GDB is not able to find the function name when reloading the core dump. Any hint?

arm64 gdb coredump
1 Answers

Just like when the OS creates a core file, the original program executable is not included in the core file itself, and it is this executable that contains the debug information (or allows GDB to find the debug information).

What this means is, if you want to debug with the debug information then you need to provide both the executable and the core file, so something like:

gdb my_program.exe -c core.pid
user_32284950
Related