无法从 gdb backtrace 获取任何信息
我有一个在 linux 64 位系统下运行的发行版服务器进程。它崩溃并留下了核心转储文件。我使用 gdb 来调试它，如下所示：
gdb svr coredump file
并得到以下回溯：
(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 进行分析，问题是什么以及如何找到 coredump 的根本原因是什么？
谢谢！
I have a release version server process running under linux 64-bit systems. It got crashed and left a coredump file. I use gdb to debug it like this:
gdb svr coredump file
And got the following backtraces:
(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 ?? ()
The address info can not be analyzed by addr2line, what is the problem and how can I find what is the root cause of coredump?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否在生成核心转储的机器上运行 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命令在加载核心之前。例如Are you running GDB on the machine on which the core dump was produced?
For GDB to correctly reconstruct the crash stack trace, it must have access to exact binaries which were used at the time of the crash (or you get garbage).
The easiest way to achieve this is to analyze the core on the machine on which it was produced. If that's not feasible, you must copy all shared libraries to e.g.
/tmp/solib-on-server/(preserve the path, so e.g./lib/libc.so.6goes into/tmp/solib-on-server/lib/libc.so.6), then use GDBset solib-absolute-prefix /tmp/solib-on-servercommand before loading the core. E.g.如果没有调试符号，调试程序是非常困难的。由于您使用的是应用程序的发行版本，核心转储将不包含任何调试信息。
我不确定，但如果您可以将堆栈跟踪与应用程序的“.map”文件关联起来，您可能会有所收获。如果我处于您的位置，我会使用调试符号（-g 编译器标志）重新编译应用程序，然后继续调试。
Its very hard to debug programs without debug symbols. As you are using release version of the application the core dump will not contain any debug information.
I am not sure, but if you can correlate the stack trace with the ".map" file of your application you could be getting somewhere. If I was in your position I would have recompiled the app with debug symbols(-g compiler flag) and then proceed on debugging.
您可以在 gdb 中使用以下命令来设置共享库路径。
[Directories] : 用冒号分隔的路径(Ex /usr/lib:/usr/lib64)
这两个命令帮助我获取了一些信息。
You can use below commands in gdb to set shared library path.
[Directories] : paths separated by colon(Ex /usr/lib:/usr/lib64)
These two commands helped me to get some info.