无法理解核心文件分析的 GDB x 命令输出

Posted

技术标签:

【中文标题】无法理解核心文件分析的 GDB x 命令输出【英文标题】:Not Able to understand the GDB x command output for a core file analysis 【发布时间】:2015-06-18 12:53:12 【问题描述】:

我的程序由于分段错误而崩溃,我有核心文件和带有调试符号的二进制文件。现在我想弄清楚它到底是在哪里崩溃的(行号、函数名等),但不幸的是,在运行 x 命令(x/256wa $sp)后,我得到了一些十六进制的信息。我是 gdb 的新手,这里的专家可以帮我弄清楚我的程序到底在哪里崩溃了,或者那些不明地址是什么。我已经粘贴了我的 x 命令输出。

0x2bc3b3b8: 0xb 0x0 0x1 0x0
0x2bc3b3c8: 0x378   0x70    0x46    0x6c700
0x2bc3b3d8: 0x7e4c8 0x0 0x370   0x2ae40248
0x2bc3b3e8: 0x2bc3b44c  0xa 0x2bc3c920  0x378
0x2bc3b3f8: 0x0 0x2ad8983c <malloc+252> 0x2b45ee04  0x370
0x2bc3b408: 0x370   0x2bc3b44c  0xa 0x370
0x2bc3b418: 0x9f1f0 0x2b4004a8  0x2b400494  0x2b45ee04
0x2bc3b428: 0x2b45f8f0  0x370   0x6c700 0x16
0x2bc3b438: 0x0 0x0 0x0 0x2
0x2bc3b448: 0x0 0xe 0x17    0x0
0x2bc3b458: 0x0 0x0 0x3e420 0x0
0x2bc3b468: 0x0 0x0 0x2bc3c460  0x152
0x2bc3b478: 0x0 0x2ab738c0  0x7ee543a4  0x2bc3b7b4
0x2bc3b488: 0x2b6c14a0  0x2bc3b728  0x2ad8db10 <strerror+36>    0x2ad8dd34 <strnlen+36>
0x2bc3b498: 0x60000010  0x0 0x0 0x0
0x2bc3b4a8: 0x8 0x0 0x1 0x2b43f5dc
0x2bc3b4b8: 0x0 0x0 0x0 0x2ab962f8 <funlockfile>
0x2bc3b4c8: 0x2bc3b538  0x0 0x0 0x0
0x2bc3b4d8: 0x0 0x0 0x2bc3b574  0x2bc3b55c
0x2bc3b4e8: 0x2b44d2f8  0x0 0x2 0x0
0x2bc3b4f8: 0x0 0x0 0x0 0x2bc3b608
0x2bc3b508: 0x81f18 0x0 0x2bc3b608  0x2b2bf884
0x2bc3b518: 0x81f18 0x697ad 0x56465001  0x120
0x2bc3b528: 0x0 0x0 0x1 0x0
0x2bc3b538: 0x0 0x1 0xf4240 0x0
0x2bc3b548: 0x0 0x0 0x0 0x0
0x2bc3b558: 0x0 0x0 0x0 0xf4240
0x2bc3b568: 0x0 0x0 0x0 0x0
0x2bc3b578: 0x0 0x0 0x0 0x0
0x2bc3b588: 0x0 0x0 0x0 0x0
0x2bc3b598: 0x0 0x0 0x0 0x0
0x2bc3b5a8: 0x0 0xff000000  0x0 0x43e00000
0x2bc3b5b8: 0x0 0x40280000  0x0 0x40200000
0x2bc3b5c8: 0x0 0x40240000  0x0 0x412e8480
0x2bc3b5d8: 0x0 0x3ff00000  0x1 0x0
0x2bc3b5e8: 0x0 0x0 0x0 0x0
0x2bc3b5f8: 0x0 0x0 0x0 0x0
0x2bc3b608: 0x0 0x0 0x0 0x0
0x2bc3b618: 0x0 0x0 0x0 0x0
0x2bc3b628: 0x60000010  0x0 0x40000000  0x8046a268
0x2bc3b638: 0x8ee25e68  0x8aaec 0x0 0x871b0
0x2bc3b648: 0x871b0 0x2b2b7450 <MSGACORE_MIMEParserFeed+8948>   0x2bc3b74c  0x2ae3f000
0x2bc3b658: 0x1 0x2ae40248  0x8aad0 0x0
0x2bc3b668: 0x1fc78 <std::deque<HashMessage, std::allocator<HashMessage> >::_M_destroy_data(std::deque<HashMessage, std::allocator<HashMessage> >::iterator, std::deque<HashMessage, std::allocator<HashMessage> >::iterator, std::allocator<HashMessage> const&)+64>   0x2ae3f000  0x0 0x0
0x2bc3b678: 0x0 0x0 0x0 0x2ae3f000
0x2bc3b688: 0x7 0x2 0x0 0x2ae40250
0x2bc3b698: 0x0 0x0 0x1 0x2ae40248
0x2bc3b6a8: 0x152   0x0 0x1fc78 <std::deque<HashMessage, std::allocator<HashMessage> >::_M_destroy_data(std::deque<HashMessage, std::allocator<HashMessage> >::iterator, std::deque<HashMessage, std::allocator<HashMessage> >::iterator, std::allocator<HashMessage> const&)+64>   0x9e388
0x2bc3b6b8: 0x7 0x2ad8b0ec <calloc+336> 0x2bc3c920  0x0
0x2bc3b6c8: 0x6 0x0 0x698d0 0x698d0
0x2bc3b6d8: 0x2bc3c460  0x152   0x0 0x871b0
0x2bc3b6e8: 0x0 0x2b5e3764 <MSG_SrvExtractMimeInfo+1512>    0x0 0x0

还有回溯:

(gdb) where
#0 0x2ad4a6bc in kill () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/lib/libc‌​.so.6
#1 <signal handler called>
#2 0x2ad8dd34 in strnlen () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/lib/libc‌​.so.6
#3 0x2ad8db10 in strerror () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/lib/libc‌​.so.6
#4 0x2bc3b780 in ?? ()
#5 0x2bc3b780 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

【问题讨论】:

如果你想知道它在哪里崩溃,只需使用where 命令,你就会得到一个回溯。如果您的二进制文件中有调试符号,则回溯将更加有用。 我尝试了 where 命令,但输出再次无法帮助我指出确切的崩溃。 (gdb) where #0 0x2ad4a6bc in kill () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/lib /libc.so.6 #1 #2 0x2ad8dd34 in strnlen () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/ lib/libc.so.6 #3 0x2ad8db10 in strerror () from /opt/xse/xse-cmu-latest-version/usr/local/sdk-imx6/arm-oe-linux-gnueabi/lib/libc.so. 6 #4 0x2bc3b780 在?? () #5 0x2bc3b780 在?? () 回溯停止:前一帧与本帧相同(损坏的堆栈?) 【参考方案1】:

您的堆栈跟踪看起来不正常。但您可以尝试使用以下原始地址获取更多信息:

addr2line -f -e programName 0x2bc3b3b8
addr2line -f -e programName 0x2bc3b698

等等

另一种选择是注册 SIGSEGV 信号。喜欢这里How to generate a stacktrace when my gcc C++ app crashes

【讨论】:

以上是关于无法理解核心文件分析的 GDB x 命令输出的主要内容,如果未能解决你的问题,请参考以下文章

python脚本转储ELF(核心和输出)?

为什么gdb core文件的时候无法定位出出问题的地方

与实际内存内容相比,GDB 内存检查输出减少了 8 个字节

GDB核心转储具有损坏的堆栈,显示“堆栈帧无法访问地址0x12处的内存”

如何在日志文件中包含GDB命令?

使用 gdb 分析核心转储帧