用gdb调试程序.docx
《用gdb调试程序.docx》由会员分享，可在线阅读，更多相关《用gdb调试程序.docx（19页珍藏版）》请在冰豆网上搜索。
用gdb调试程序
在linux的c编程中大家经常用gdb调试程序，以下是一些常用的指令
1.breakFUNCTION
在某个函数上设置断点。
函数重载时，有可能同时在几个重载的函数上设置了断点
break+OFFSET
break-OFFSET
在当前程序运行到的前几行或后几行设置断点
breakLINENUM
在行号为LINENUM的行上设置断点
breakFILENAME:
LINENUM
在文件名为FILENAME的原文件的第LINENUM行设置断点
breakFILENAME:
FUNCTION
在文件名为FILENAME的FUNCTION函数上设置断点
当你的多个文件中可能含有相同的函数名时必须给出文件名。
break*ADDRESS
在地址ADDRESS上设置断点，这个命令允许你在没有调试信息的程序中设置断点
break
当break命令不包含任何参数时，break命令在当前执行到的程序运行栈中的
下一条指令上设置一个断点。
除了栈底以外，这个命令使程序在一旦从当前
函数返回时停止。
相似的命令是finish，但finish并不设置断点。
这一点在
循环语句中很有用。
gdb在恢复执行时，至少执行一条指令。
break...ifCOND
这个命令设置一个条件断点，条件由COND指定；在gdb每次执行到此断点时
COND都被计算当COND的值为非零时，程序在断点处停止
ignoreBNUMCOUNT'
设置第BNUM号断点的被忽略的次数为'COUNT'，即断点BNUM再执行到第COUNT+1
次时程序停止
tbreakARGS或者简写为tb
设置断点为只有效一次。
ARGS的使用同break中的参量的使用
hbreakARGS
设置一个由硬件支持的断点。
这个命令的主要目的是用于对EPROM/ROM程序的调试
因为这条命令可以在不改变代码的情况下设置断点。
这可以同SPARCLiteDSU一起
使用。
当程序访问某些变量和代码时，DSU将设置“陷井”。
注意：
你只能一次使用
一个断点，在新设置断点时，先删除原断点
thbreakARGS'
设置只有一次作用的硬件支持断点
rbreakREGEX
在所有满足表达式REGEX的函数上设置断点。
这个命令在所有相匹配的函数上设置无
条件断点，当这个命令完成时显示所有被设置的断点信息。
这个命令设置的断点和
break命令设置的没有什么不同。
当调试C++程序时这个命令在重载函数上设置断点时
非常有用。
infobreakpoints[N]
infobreak[N]
infowatchpoints[N]
显示所有的断点和观察点的设置表，有下列一些列
*BreakpointNumbers*----断点号
*Type*----断点类型（断点或是观察点）
*Disposition*---显示断点的状态
*EnabledorDisabled*---使能或不使能。
'y'表示使能，'n'表示不使能。
*Address*----地址，断点在你程序中的地址（内存地址）
*What*---地址，断点在你程序中的行号。
如果断点是条件断点，此命令还显示断点所需要的条件。
带参数N的'infobreak'命令只显示由N指定的断点的信息。
此命令还显示断点的运行信息（被执行过几次），这个功能在使用'ignore'
命令时很有用。
你可以'ignore'一个断点许多次。
使用这个命令可以查看断点
被执行了多少次。
这样可以更快的找到错误。
maintinfobreakpoints
显示所有的断点，无论是你设置的还是gdb自动设置的。
断点的含义：
breakpoint：
断点，普通断点
watchpoint：
普通观察点
longjmp：
内部断点，用于处理'longjmp'调用
longjmpresume：
内部断点，设置在'longjmp'调用的目标上
until：
'until'命令所使用的内部断点
finish：
finish'命令所使用的内部断点
2.watchEXPR
为表达式（变量）expr设置一个观察点。
一量表达式值有变化时，马上停住程序。
这个命令使用EXPR作为表达式设置一个观察点。
GDB将把表达式加入到程序中并监
视程序的运行，当表达式的值被改变时GDB就使程序停止。
这个也可以被用在SPARClite
DSU提供的新的自陷工具中。
当程序存取某个地址或某条指令时（这个地址在调试寄
存器中指定）,DSU将产生自陷。
对于数据地址DSU支持'watch'命令,然而硬件断点寄
存器只能存储两个断点地址，而且断点的类型必须相同。
就是两个'rwatch'型断点
或是两个'awatch'型断点。
rwatchEXPR'
设置一个观察点，当EXPR被程序读时，程序被暂停。
awatchEXPR'
设置一个观察点,当EXPR被读出然后被写入时程序被暂停。
infowatchpoints
在多线程的程序中，观察点的作用很有限，GDB只能观察在一个线程中的表达式的值
如果你确信表达式只被当前线程所存取，那么使用观察点才有效。
GDB不能注意一个
非当前线程对表达式值的改变。
rwatch
当表达式（变量）expr被读时，停住程序。
awatch
当表达式（变量）的值被读或被写时，停住程序。
infowatchpoints
列出当前所设置了的所有观察点。
3.catchEXCEPTIONS
使用这个命令在一个被激活的异常处理句柄中设置断点。
EXCEPTIONS是一个你要抓住
的异常。
你一样可以使用'infocatch'命令来列出活跃的异常处理句柄。
GDB中对于异常处理由以下情况不能处理：
*如果你使用一个交互的函数，当函数运行结束时，GDB将象普通情况一样把控制返
回给你。
如果在调用中发生了异常，这个函数将继续运行直到遇到一个断点，一个信号
或是退出运行。
*你不能手工产生一个异常（即异常只能由程序运行中产生）
*你不能手工设置一个异常处理句柄。
有时'catch'命令不一定是调试异常处理的最好的方法。
如果你需要知道异常产生的
确切位置，最好在异常处理句柄被调用以前设置一个断点，这样你可以检查栈的内容。
如果你在一个异常处理句柄上设置断点，那么你就不容易知道异常发生的位置和原因。
要仅仅只在异常处理句柄被唤醒之前设置断点，你必须了解一些语言的实现细节。
3.contN
第N次经过该断点时才停止程序运行
4.enable断点编号
恢复暂时失活的断点，要恢复多个编号的断点，可用空格将编号分开
5.disable断点编号
使断点失效，但是断点还在
6.delete断点编号或者表达式
删除某断点
7.clear断点所在行号
清除某断点
8.查看断点列表
infobreak
9.watchcounter>15
当counter>15的时候程序终止
10.当程序崩溃的时候linux会生成一个core文件，可以用
gdba.outcore
where
查看导致崩溃的原因
11.continue
恢复程序运行，直到遇到下一个断点
12.run
程序开始运行，直到遇到断点
13.step
执行一行代码
14.next
和s不同的是他不跟踪到代码的内部，一步一步执行代码
15.直接回车为执行上一个命令
16.print变量
打印某一变量的值
17.display变量
每次运行到断点就显示变量的值，用于观察变量的变化
18.set变量=
在程序执行中重新设置某变量的值
19.printf"%2.2s\n",（char*）0x120100fa0
结果打印出：
He
20.设置gdb的列宽,以下为将屏幕设置为70列
setwidth70
21.infoargs列出你程序所接受的命令行参数
inforegisters列出寄存器的状态
infobreakpoint列出在程序中设的断点
要获得详细的关于info的信息用helpinfo.
22.set
这个命令用来为你的程序设置一个运行环境（使用一个表达式）。
setprompt$把gdb的提示符设为$.
setargs可指定运行时参数。
（如：
setargs1020304050）
showargs命令可以查看设置好的运行参数。
23.show
show命令用来显示gdb自身的状态。
使用'set'命令可以改变绝大多数由'show'显示的信息
使用showradix命令来显示基数
用不带任何参变量的'set'命令可以显示所有可以设置的变量的值
有三个变量是不可以用'set'命令来设置的:
showversion显示gdb的版本号
showcopying显示版权信息
showwarranty显示担保信息
【转】 GDB结合CoreFile巧妙分析Crash原因
2011-08-1611:
30
转载自 分享
最终编辑 sheenshine
编写服务器端程序，很容易遇到Crash问题，比较幸运的是Linux提供了corefile，保留了Crash的现场。
有时候，根据当前的调用栈，并且打印出当前栈的变量就可以分析出crash的原因，但是，有时候看到调用栈却束手无策。
下面就介绍自己通过GDB的几个命令的结合，发现一个crash的原因的过程。
下面让我们一起进入现场，来逐步发现其中的原因。
首先，还是运行gdb 命令，gdbwbxgscore.5797,来看看现场。
[root@hfgs126bin]# gdbwbxgs_crashcore.5797
GNUgdbRedHatLinux（6.3.0.0-1.132.EL4rh）
……
#0 0x00000038e8d70540instrlen（）from/lib64/tls/libc.so.6
（gdb） bt
#0 0x00000038e8d70540instrlen（）from/lib64/tls/libc.so.6
#1 0x000000000057cfc0inT120_Trace:
:
Text_Formator:
:
advance（this=0x7e800a70,lpsz=0x1）
at./t120trace.cpp:
1464
#2 0x000000000057ceb1inT120_Trace:
:
Text_Formator:
:
operator<<（this=0x7e800a70,lpsz=0x1）
at./t120trace.cpp:
1411
#3 0x0000000000407927in~func_tracer（this=0x7e804bd0）at../h/t120trace.h:
381
#4 0x00000000004432fdinCGSSocketServer:
:
readHeader（this=0x8e4130,socketfd=1088,
buf=0x7e806cc0"GET/detectService?
cmd=selfcheckHTTP/1.1\r\nConnection:
Close\r\nHost:
10.224.122.94\r\n\r\n",bufsize=1024）
atmgr/gssocketserver.cpp:
337
#5 0x0000000000443981inCGSSocketServer:
:
handle（this=0x8e4130,socketfd=1088,strRet=@0x7e807190）atmgr/gssocketserver.cpp:
424
#6 0x0000000000442f5einCGSSocketServer:
:
readThread（pArg=0x9ae9c0）atmgr/gssocketserver.cpp:
304
#7 0x00000038e980610ainstart_thread（）from/lib64/tls/libpthread.so.0
#8 0x00000038e8dc68b3inclone（）from/lib64/tls/libc.so.6
#9 0x0000000000000000in?
?
（）
通过这个调用栈，可以看出，程序crash在打log的时候。
虽然遇到过类似的crash，但是，当时的原因是有死循环，通过reviewcode，没有发现死循环。
但是当前的调用栈对于分析Crash的原因是一点用也没有，如果分析具体的原因呢？
会不会是其他得线程出现错误导致程序Crash在这个线程呢？
为了找到深一层的原因，尝试着通过GDB的一些关于线程的命令，来看看其他的线程是否有问题。
于是，使用infothreads，查看了一下当时线程的情况。
（gdb） infothreads
21process5797 0x00000038e8d7186dinmemset（）from/lib64/tls/libc.so.6
20process5839 0x00000038e8dc6c8cinepoll_wait（）from/lib64/tls/libc.so.6
19process5842 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
18process5845 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
17process5846 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
16process5847 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
15process5848 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
14process5849 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
13process5850 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
12process5852 0x00000038e8dbf946in__select_nocancel（）from/lib64/tls/libc.so.6
11process5854 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
10process5856 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
9process5857 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
8process5858 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
7process5859 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
6process5861 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
5process5862 0x00000038e980a66finsem_wait（）from/lib64/tls/libpthread.so.0
4process5863 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
3process5864 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
2process5883 0x00000038e8d8f7d5in__nanosleep_nocancel（）from/lib64/tls/libc.so.6
*1process5853 0x00000038e8d70540instrlen（）from/lib64/tls/libc.so.6
对于线程如果停止在sleep或者wait的情况，都是正常的，但是我们看到thread21有些异常，程序停止在memset，不管是否有问题，都需要看看这样的线程具体有没有出错。
于是通过命令thread21，进入到thread21的调用栈。
（gdb） thread21
[Switchingtothread21（process5797）]#0 0x00000038e8d7186dinmemset（）from/lib64/tls/libc.so.6
（gdb） bt
#0 0x00000038e8d7186dinmemset（）from/lib64/tls/libc.so.6
#1 0x000000000049da0dinCGSPduFactory:
:
streamStringFrom（is=@0x7fff9b436360,strFrom=@0x2aaaec979760）atcommon/pdu/gspdu.cpp:
422
#2 0x00000000004d1f25inCGSOthShardUserRspPdu:
:
streamFrom（this=0x2aaaec951650,is=@0x7fff9b436360）atcommon/pdu/pdugs.cpp:
2707
#3 0x000000000049cb2dinCGSPduFactory:
:
derivePdu（is=@0x7fff9b436360,ulPDULen=30506）atcommon/pdu/gspdu.cpp:
79
#4 0x000000000049c78einCGSPduFactory:
:
streamPduFrom（pDataPacket=0x2aaaeca31d70）atcommon/pdu/gspdu.cpp:
35
#5 0x0000000000449681inCGSWDMSManager:
:
on_wdms_message_indication（this=0x8e3680,msg=0x2aaae9894360）
atmgr/gswdmsmanager.cpp:
344
……
#180x0000000000407733inmain（argc=1,argv=0x7fff9b44ac98）atgsmain.cpp:
118
（gdb） f3
#3 0x000000000049cb2dinCGSPduFactory:
:
derivePdu（is=@0x7fff9b436360,ulPDULen=30506）atcommon/pdu/gspdu.cpp:
79
79 common/pdu/gspdu.cpp:
Nosuchfileordirectory.
incommon/pdu/gspdu.cpp
使用命令 ilocals，打印所有的变量的值。
（gdb） ilocals
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={
staticnpos=18446744073709551615,
_M_dataplus={:
allocator>={<__gnu_cxx:
:
new_allocator>={},},
_M_p=0x2aaaeca52a68"10.224.95.109:
9900"}},m_strSubject={staticnpos=18446744073709551615,
_M_dataplus={:
allocator>={<__gnu_cxx:
:
new_allocator>={},},
_M_p=0x2aaaec929b28"qawin.qazone.GS"}},m_ulSequence=0}
从蓝色的字的部分可
升级会员 