gdb symbols loaded but no symbols shown for seg fault

Question

So I have my core dump after setting the ulimit: (ulimit -c unlimited)

The core dump comes from another system that is experiencing some issues.

I have copied the core over to my dev system to examine it.

I go into gdb:

$ gdb -c core
...
Core was generated by `./ovcc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fedd95678a9 in ?? ()
[Current thread is 1 (LWP 15155)]
(gdb) symbol-file ./ovcc
Reading symbols from ./ovcc...
(gdb) bt
#0  0x00007fedd95678a9 in ?? ()
#1  0x0000000000000002 in ?? ()
#2  0x000055e01cd5e7e0 in ?? ()
#3  0x00007fedd21e9e00 in ?? ()
#4  0x0000000000000201 in ?? ()
#5  0x000055e01cd5e7e0 in ?? ()
#6  0x0000000000000201 in ?? ()
#7  0x0000000000000000 in ?? ()
(gdb)

I check the compile and link commands and they both have "-g" and I can visually step through the program with the codium debugger!

So why can't I see where the executable is crashing?

What have I missed?

Is the problem the fact that the core was created on another system?

Answer 1

Is the problem the fact that the core was created on another system?

Yes, exactly.

See this answer for possible solutions.

Update:

So does this mean I can only debug the program on the system where it is both built and crashes?

It is certainly not true that you can only debug a core on the system where the binary was both built and crashed -- I debug core dumps from different systems every day, and in my case the build host, the host where the program crashed, and the host on which I debug are all separate.

One thing I just noticed: your style of loading the core: gdb -c core followed by symbol-file, doesn't work for PIE executables (at least when using GDB 10.0) -- this may be a bug in GDB.

The "regular" way of loading the core is:

gdb ./ovcc core

See if that gives you better results. (You still need to arrange for matching DSOs, as linked answer shows how to do.)