无法理解核心文件分析的 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 您的堆栈跟踪看起来不正常。但您可以尝试使用以下原始地址获取更多信息:
addr2line -f -e programName 0x2bc3b3b8
addr2line -f -e programName 0x2bc3b698
等等
另一种选择是注册 SIGSEGV 信号。喜欢这里How to generate a stacktrace when my gcc C++ app crashes
【讨论】:
以上是关于无法理解核心文件分析的 GDB x 命令输出的主要内容,如果未能解决你的问题,请参考以下文章