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

【问题标题】：GDB debugging trace with no relevant info (#0 0x2e6e6f69 in ?? ())没有相关信息的 GDB 调试跟踪（#0 0x2e6e6f69 in ?? ()）
【发布时间】：2013-04-22 12:11:56
【问题描述】：

在使用 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 标志。相同的二进制文件生成了我已修复的正常内核（具有正确调试信息的内核）。

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

【问题讨论】：

标签： linux gdb segmentation-fault coredump memory-corruption

【解决方案1】：

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

这些是一些指针。如果我记得更多，我会更新答案。 HTH！

【讨论】：

@user2307143：对你有帮助吗？真正的问题是什么？如果您提出实际问题和解决方案（并且可能会投票相关的答案），这将有助于其他成员滚动解决类似问题。
否。我在编译时使用了 -g 标志。我根本没有使用-O。我也交叉检查了，空间足够了。我的开发和生产环境是一样的。最初从您的评论中，我虽然空间可能是问题。但它不是。我无法找到解决方案。该代码多次访问相同的功能，但有些如何在 3-4 天后产生分段错误，核心除了 menu_table 功能外没有相关信息。

【解决方案2】：

gdb pull core.11328

Core was generated by ./ussd_pull_gw ...`

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

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

【讨论】：

谢谢。现在我使用了正确的二进制文件。但结果还是一样。调试环境和开发环境相同。用于生成正确内核的相同二进制文件。我已经解决了这些问题，但现在它的生成没有调试信息。
@user2307143 “调试和开发环境是一样的”——这是否意味着您在同一台机器上记录核心转储并对其进行分析？ “但现在它的生成没有调试信息”——请更新您的问题；我怀疑您得到的输出是否与以前相同。
是的。我在生产机器上启用了 -g 标志并在同一台机器上编译代码。 “没有调试信息”意味着它生成的调试信息不足以进行调试，如您在上面附加的跟踪中所见。我只能看到 menu_table 函数，然后是一些十六进制地址。请提出可能是什么问题。