没有相关信息的GDB调试跟踪(#0 0x2e6e6f69 in ??())



在调试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标志。相同的二进制文件已经生成了正常的核心(核心与适当的调试信息),我已经修复。

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

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

这些是一些指针。如果我再回忆一些,我会更新答案。HTH !

gdb pull core.11328

Core was generated by ./ussd_pull_gw…'

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

您需要使用与生成核心的完全相同的可执行文件。例如,用-g而不是-O2重新构建可执行文件将导致您观察到的结果(但用-g -O2重新构建通常有效)。

相关内容

  • 没有找到相关文章

最新更新