GDB调试跟踪没有相关信息（＃（）中的＃0 0x2e6e6f69） [英] GDB debugging trace with no relevant info (#0 0x2e6e6f69 in ?? ())

问题描述

在使用GDB进行调试时，我面临着特定的挑战。我的二进制文件生成核心。当我调试它的GDB。我没有得到相关的调试信息。

  GDB堆栈跟踪（bt）： -  
 
 [root （g）红帽企业Linux（7.0.1-23.el5）
自由软件基金会版权所有（c）2009 
许可证GPLv3 +：GNU GPL版本3或更高版本< http：//gnu.org/licenses/gpl.html> 
这是免费软件：您可以自由更改和重新分配它。 
在法律允许的范围内，不存在任何担保。有关详细信息，请键入显示复制
和显示保修。 
这个GDB被配置为i386-redhat-linux-gnu。 
有关错误报告的说明，请参阅：
< http：//www.gnu.org/software/gdb/bugs/> ... 
从/ home / abc读取符号/xyz/bin/pull...done。 
 [New Thread 11379] 
 [New Thread 11378] 
 [New Thread 11377] 
 [New Thread 11376] 
读取/lib/libpthread.so中的符号。 0 ...（没有找到调试符号）...完成。 
为/lib/libpthread.so.0加载了符号
从/lib/libm.so.6...中读取符号（没有找到调试符号）...完成。 
为/lib/libm.so.6加载了符号
从/opt/septel/lib32/libgctlib.so.1...中读取符号（没有找到调试符号）...完成。 
为/opt/septel/lib32/libgctlib.so.1加载了符号
从/lib/libc.so.6...中读取符号（没有找到调试符号）...完成。 
为/lib/libc.so.6加载了符号
从/lib/ld-linux.so.2...中读取符号（没有找到调试符号）...完成。 
为/lib/ld-linux.so.2加载了符号
从/lib/libnss_files.so.2...中读取符号（没有找到调试符号）...完成。 
 /lib/libnss_files.so.2的加载符号
核心是由`./pull -c /home/abc/xyz/conf/Common.cfg -g / home / abc / xyz / 。 
程序终止于信号11，分段故障。 
＃0 0x2e6e6f69在?? （）
（gdb）bt 
＃0 0x2e6e6f69 in ?? （）
＃1 0x40310738在？ （）
＃2 0x20459102 in menu_table（）
＃3 0x31073900 in ?? （）
＃4 0x35910240在？ （）
＃5 0x01530084 in ?? （）
＃6 0x00000052在？ （）
＃7 0x00000000 in ?? （）
（gdb）q 
  

bt和bt full没有显示任何有用的信息。我已经编写了我的二进制-g标志。同样的二进制产生了正常的核心（具有正确的调试信息的核心），我已经修复。

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

解决方案

下面的指针可以帮助你检查调试信息 -

1.检查你是否编译过带有调试信息的代码。 （例如-g和优化标志关闭-O（2/3/4/5））等。

2.在核心代中检查 - 您的系统中有足够的空间。截断的核心文件将不会有完整的细节来检查符号。

3.检查调试环境是否与运行环境完全相同（如果两者位于不同位置）。不正确的环境也会导致未知的符号。

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

I am facing a specific challenge while debugging with GDB. My binary is generating core. When i am debugging it GDB. I am not getting relevant debugging information.

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 and bt full is not showing any useful info. I have complied my binary -g flag. The same binary had generated normal core (core with proper debugging info) that had i have fixed.

In this particular case i am not able to identify any issue. Please suggest how i can debug and resolve the issue.

解决方案

Below pointers may help you to check the debugging info -
1. Check if you have compiled your code with debugging info on. (like -g and optimization flag off -O(2/3/4/5)) etc.
2. Check during the core generation - you have sufficient space in your system. A truncated core file will not have complete details to check for symbols.
3. Check if the debugging environment is exactly same as the run environment (in case both are at different location). An incorrect environment also can lead to unknown symbols.

These are some pointer. If I recall some more, I will update the answer. HTH!

这篇关于GDB调试跟踪没有相关信息（＃（）中的＃0 0x2e6e6f69）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！