Question

在使用GDB进行调试时，我遇到了一个特定的挑战。我的二进制文件生成核心。当我调试GDB时。我没有收到相关的调试信息。

GDB stack trace (bt):-

[root@ussdgw5 bin]# gdb pull core.11328
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/abc/xyz/bin/pull...done.
[New Thread 11379]
[New Thread 11378]
[New Thread 11377]
[New Thread 11376]
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /opt/septel/lib32/libgctlib.so.1...(no debugging symbols found)...done.
Loaded symbols for /opt/septel/lib32/libgctlib.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `./pull -c /home/abc/xyz/conf/Common.cfg -g /home/abc/xyz/'.
Program terminated with signal 11, Segmentation fault.
#0  0x2e6e6f69 in ?? ()
(gdb) bt
#0  0x2e6e6f69 in ?? ()
#1  0x40310738 in ?? ()
#2  0x20459102 in menu_table ()
#3  0x31073900 in ?? ()
#4  0x35910240 in ?? ()
#5  0x01530084 in ?? ()
#6  0x00000052 in ?? ()
#7  0x00000000 in ?? ()
(gdb) q

bt和bt full没有显示任何有用的信息。我已经完成了我的二进制-g标志。相同的二进制文件生成了正常的核心（具有适当调试信息的核心），我已经修复了它。

在这种特殊情况下，我无法识别任何问题。请建议我如何调试和解决问题。

Answer 1

指针下方可帮助您查看调试信息 -
1.检查是否已使用调试信息编译代码。（例如-g和优化标志关闭-O（2/3/4/5））等 2.在核心生成期间检查 - 您的系统中有足够的空间。截断的核心文件将没有完整的详细信息来检查符号 3.检查调试环境是否与运行环境完全相同（如果两者位于不同的位置）。不正确的环境也可能导致未知符号。

这些是一些指针。如果我再回忆一下，我会更新答案。 HTH！

Answer 2

gdb pull core.11328

Core was generated by ./ ussd_pull_gw ...`

您遇到麻烦的最可能原因是二进制不匹配：您可能正在分析由不同可执行文件生成的核心。

您需要使用生成核心的完全相同的可执行文件。用例如重建可执行文件-g代替-O2会导致您观察到的结果（但使用-g -O2进行重建通常会有效。）

没有相关信息的GDB调试跟踪（??（）中的＃0 0x2e6e6f69）

2 个答案: