GDB---coredump分析

==============coredump文件产生设置=====release版本coredump的调试===============================================================
无-g编译的coredump以后怎么定位问题。以前都是用debug版本调试，然后出现问题也好定位，没关注过release版本怎么定位问题。今天就记录下怎么调试coredump。
调试方法
最好是把GCC编译选项-Wall打开，让所有编译警告都显示出来，并认真解决警告，有时候不处理警告会导致大问题；使用-g编译debug版本调试；设置系统能生成coredump文件。
1.core dump设置方式
(1)设置生成core dump文件
默认是不会产生core dump文件的，通过ulimit -c来查看core dump文件的大小，一般开始是0，设置ulimit -c unlimited后就能产生core dump文件。
(2)设置core dump文件名称
默认情况下，linux程序崩溃后会在可执行程序的目录下生成文件名称为core的文件，当然可以设置每次崩溃后的core dump文件名称为core+可执行文件名+pid这样的名称以便保留之前的core dump文件。
echo 'core.%e.%p' > /proc/sys/kernel/core_pattern
可以在core_pattern模板中使用变量还很多，见下面的列表：
%% 单个%字符
%p 所dump进程的进程ID
%u 所dump进程的实际用户ID
%g 所dump进程的实际组ID
%s 导致本次core dump的信号
%t core dump的时间 (由1970年1月1日计起的秒数)
%h 主机名
%e 程序文件名
2.如何调试coredump文件定位问题
(1)有-g编译的debug程序core dump后
test_debug为debug版本可执行程序
core.test_debug.30234为debug版本core dump文件
当程序core dump后用gdb命令加载core文件调试：gdb test_debug core.test_debug.30234
bt
l
info thread
(2)无-g编译的release程序coredump后
test_release为release版本可执行程序
core.test_release.30254为release版本core dump文件
gdb命令：gdb test_debug core.test_release.30254
命令格式就是gdb debug的可执行程序 release的core文件。
(3)调试无-g编译的release程序，这题与core dump文件无关
步骤1.相同的代码编译debug版本test_debug和release版本test_release;
步骤2.objcopy --only-keep-debug test_debug projectsymbol.dbg #生成符号表；
步骤3.gdb -q --symbol=projectsymbol.dbg -exec=test_release#加载符号表；
步骤4.像调试debug一样可以调试release了（不过我觉得这是多此一举，既然这台机器可以编译跑debug，为啥还要弄release呢？呵呵）
==============引入库===============================================================
(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          /lib/libncore.so
                        No          /lib/libicuuc.so
可以看到很多库的符号表都没有被读入，看来果然如此。
输入用set solib-search-path + 库的路径 指定所要读取的符号表动态库所在位置，结果会看到很多done之类的信息，说明加载成功，  
现在bt下就能看到堆栈的详细信息了。
(gdb) bt
#0  nutshell::SourceUSB_ScannerThread::setScannerState (this=0x0,
    state=nutshell::SourceUSB_ScannerThread::SCANNERSTATE_START)
    at system/MediaLibrary/SourceUSB/src/Thread_Scanner/SourceUSB_ScannerThread.cpp:138
#1  0x2ae1ce1a in nutshell::SourceUSB_Scanner_EventHandler::onHandle (this=0xaf4a0, cEvt=...)
============查看线程信息，frame信息，变量信息==========================================
看样子是个多线程的应用，用threads命令看看都有哪些线程，切换过去逐个再bt
(gdb) info threads
  21 process 5797  0x00000038e8d7186d in memset () from /lib64/tls/libc.so.6
  20 process 5839  0x00000038e8dc6c8c in epoll_wait () from /lib64/tls/libc.so.6
(gdb) thread 21
[Switching to thread 21 (process 5797)]#0  0x00000038e8d7186d in memset () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x00000038e8d7186d in memset () from /lib64/tls/libc.so.6
(gdb) f 3
#3  0x000000000049cb2d in CGSPduFactory::derivePdu (is=@0x7fff9b436360, ulPDULen=30506) at common/pdu/gspdu.cpp:79
使用命令　i locals，打印所有的变量的值。
(gdb) i locals
pPdu = (CBasePdu *) 0x2aaaec951650
pPduHeader = (CPduHeader *) 0x2aaaea1c4190
ulPduType = 50
到现在还没有看出有什么明显的异常，然后再把ＰＤＵ的头打印出来如下：
(gdb) p *pPduHeader
$1 = {m_ulHeadLen = 61, m_ulVersion = 2080000, m_ulPduType = 50, m_ulSrcSvrType = WEBEX_CONNECT_GS, m_strSrcSvrAddr = {
(gdb) f 1
#1  0x000000000049da0d in CGSPduFactory::streamStringFrom (is=@0x7fff9b436360, strFrom=@0x2aaaec979760) at common/pdu/gspdu.cpp:422
422                  in common/pdu/gspdu.cpp
(gdb) i locals
strTmp = 0x2aaaf1c00010 ""
iRet = 0
ulLen = 1179995975

转载于:https://www.cnblogs.com/xfei-zhang/p/5086859.html