我有一个发行版服务器进程在linux 64位系统下运行，它崩溃了，留下了一个coredump文件，我用gdb调试它，如下所示：
gdb服务器核心转储文件
得到了以下回溯：
(gdb) where
#0 0x0000000000432691 in ?? ()
#1 0x00002b07655a50cc in ?? ()
#2 0x00002b07655a50c4 in ?? ()
#3 0x00007fff9fade920 in ?? ()
#4 0x0000000000439db3 in ?? ()
#5 0x00007fff9fade910 in ?? ()
#6 0x00007fff9fade910 in ?? ()
#7 0x00007fff9fade8e0 in ?? ()
#8 0x00000000004663e2 in ?? ()
#9 0x00007fff9fade910 in ?? ()
#10 0x00007fff9fade910 in ?? ()
#11 0x00007fff9fade930 in ?? ()
#12 0x0000000000605108 in ?? ()
#13 0x00002b07655a274c in ?? ()
#14 0x0000000000ebc678 in ?? ()
#15 0x169f49f100000001 in ?? ()
#16 0x00000000021dc6c0 in ?? ()
#17 0x00002b07655a284c in ?? ()
#18 0x00002b07655a27dc in ?? ()
#19 0x00007fff9fade960 in ?? ()
#20 0x000000000043a03b in ?? ()
#21 0x00007fff9fade960 in ?? ()
#22 0x0000000000994d02 in ?? ()
#23 0x00000000000ecd57 in ?? ()
#24 0x00002b07655a274c in ?? ()
#25 0x00002b07655a274c in ?? ()
#26 0x00002b07655a27dc in ?? ()
#27 0x00007fff9fade980 in ?? ()
#28 0x000000000060a5eb in ?? ()
#29 0x000000009fadeb50 in ?? ()
#30 0x00002b07655a274c in ?? ()
#31 0x00007fff9fade9d0 in ?? ()
#32 0x000000000060a8f0 in ?? ()
#33 0x00007fff9fadeb50 in ?? ()
#34 0x00007fff9fadea10 in ?? ()
#35 0x00002b07655a274c in ?? ()
#36 0x00007fff9fadea10 in ?? ()
#37 0x000000009fade9d0 in ?? ()
#38 0x00007fff9fadeb58 in ?? ()
#39 0x0000000000000000 in ?? ()addr2line无法分析地址信息，问题是什么？如何找到核心转储的根本原因？
谢谢!
3条答案
按热度按时间qlckcl4x1#
您是否在生成核心转储的机器上运行GDB？
为了让GDB正确地重建崩溃堆栈跟踪，它必须能够访问在崩溃时使用的 * 精确 * 二进制文件（否则会得到垃圾）。
最简单的方法是在生产内核的机器上分析内核，如果这不可行，你必须复制所有的共享库到
/tmp/solib-on-server/（保留路径，例如/lib/libc.so.6到/tmp/solib-on-server/lib/libc.so.6），然后使用GDBset solib-absolute-prefix /tmp/solib-on-server命令 before 加载内核。rsaldnfx2#
没有调试符号很难调试程序。因为你使用的是应用程序的发布版本，核心转储将不包含任何调试信息。
我不确定，但如果你能将堆栈跟踪与应用程序的.map文件关联起来，你可能会有所收获。如果我是你，我会用调试符号（-g编译器标志）重新编译应用程序，然后继续调试。
1yjd4xko3#
您可以在gdb中使用以下命令来设置共享库路径。
设置solib搜索路径[目录]
[目录]：用冒号分隔的路径（Ex /usr/lib：/usr/lib 64）
显示solib搜索路径
这两个命令帮助我获得了一些信息。