gdb符号已加载，但没有显示seg故障的符号

Question

因此，在设置了ulimit之后，我就有了我的核心转储：(ulimit -c无限)

核心转储来自另一个正在经历一些问题的系统。

我已经将核心复制到了我的开发系统中来检查它。

我进入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)

我检查编译和链接命令，它们都有"-g“，我可以用codium调试器直观地执行程序！

那么，为什么我看不到可执行文件在哪里崩溃呢？

我错过了什么？

问题是核心是在另一个系统上创建的吗？

Answer 1

的问题是，核心是在另一个系统上创建的吗？

是的，完全正确。

有关可能的解决方案，请参见this answer。

更新：

，这是否意味着我只能在编译和崩溃的系统上调试程序？

当然，你只能在二进制文件生成和崩溃的系统上调试核心--我每天都会调试来自不同系统的核心转储，而在我的例子中，构建主机、程序崩溃的主机和我调试的主机都是独立的。

我刚刚注意到一件事:加载core：gdb -c core和symbol-file的方式不适用于饼式可执行文件(至少在使用GDB 10.0时是这样) --这可能是GDB中的一个bug。

加载核心的“常规”方式是：

gdb ./ovcc core

看看能不能给你更好的结果。(您仍然需要安排匹配的do，因为链接的答案显示了如何做。)