GDB调试器.docx

上传人:b****0 文档编号:18088343 上传时间:2023-08-13 格式:DOCX 页数:13 大小:569.47KB
下载 相关 举报
GDB调试器.docx_第1页
第1页 / 共13页
GDB调试器.docx_第2页
第2页 / 共13页
GDB调试器.docx_第3页
第3页 / 共13页
GDB调试器.docx_第4页
第4页 / 共13页
GDB调试器.docx_第5页
第5页 / 共13页
GDB调试器.docx_第6页
第6页 / 共13页
GDB调试器.docx_第7页
第7页 / 共13页
GDB调试器.docx_第8页
第8页 / 共13页
GDB调试器.docx_第9页
第9页 / 共13页
GDB调试器.docx_第10页
第10页 / 共13页
GDB调试器.docx_第11页
第11页 / 共13页
GDB调试器.docx_第12页
第12页 / 共13页
GDB调试器.docx_第13页
第13页 / 共13页
亲,该文档总共13页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

GDB调试器.docx

《GDB调试器.docx》由会员分享,可在线阅读,更多相关《GDB调试器.docx(13页珍藏版)》请在冰点文库上搜索。

GDB调试器.docx

GDB调试器

GDB调试器

应用程序的调试是开发过程中必不可少的环节之一。

Linux下的GNU的调试器称为GDB(GNUDebugger)。

该软件按是用来调试C和C++语言程序的调试器,它能使开发者在程序运行时观察程序的内部结构和内存使用情况。

GDB主要可以完成下面4个方面的功能:

(1)启动程序,按照程序员自定义的要求运行程序。

(2)单步执行、设置断点,可以让被调试的程序在所指的断点处停住。

(3)监视程序中变量的值。

(4)动态地改变程序的执行环境,如可以不退出GDB就执行shell。

GDB的命令很多,可以通过help来查看。

help命令只列出了GDB的命令种类。

如果要查看某一种类下的具体命令,可以再help命令后加类名。

如helprunning

GDB常用命令描述

break设置断点

continue从断点处开始继续执行

list列出源文件内容

info查看程序的各种信息

next执行一行代码,从而执行其整体的一个函数

print显示变量或表达式的值

quit退出GDB

run执行当前被调试的程序

backtrace显示程序中的当前位置和表示如何到达当前位置的栈跟踪

cd改变当前的工作目录

clear清除停止处的断点

delete删除一个断点或监测点

display程序停止时显示变量或表达式

file装入要调试的可执行文件

kill终止正在调试的程序

make是用户不退出GDB就可以重新产生可执行文件

set给变量赋值

shell不退出GDB就执行UNIXshell命令

step执行一行代码且进入函数内部

watch设置监视点,使用户能监视一个变量或表达式的值而不管它何时变化

例子1.

下面通过一个例子test.c介绍GDB的基本使用方法。

//test.c

使用GDB调试器,必须在编译时加入调试选项-g,命令如下:

#gcc-gtest.c-otest

进入gdb调试环境

#gdbtest

说明:

l相当于list,查看源代码

说明:

break9:

在源代码第9行设置断点

breaksum:

在源代码sum函数处设置断点

infobreak:

显示断点信息

说明:

r:

运行程序(run),在第1个断点处停住

n:

相当于next,单步执行

prints:

输出变量s的值

c:

相当于continue,继续执行,到下一个断点停住

说明:

q:

退出gdb

例子2.

下面的程序植入了错误,通过这个存在错误的程序掌握如何利用GDB进行程序调试。

//bug.c

预期结果:

#str:

hello

#thereversestring:

olleh

实际运行结果:

这时我们就可以用gdb来查看问题在哪里。

说明:

l:

列出源文件内容

说明:

break14:

在源代码第14行设置断点

r:

运行程序,在第1个断点处停住

说明:

n:

相当于next,单步执行

printlen:

输出变量len

通过以上调试过程可见,错误的根源在于没有给rev_string[0]赋值,所以rev_string[0]为’\0’,导致字符串输出为空。

可以将rev_string[len-i]改成rev_string[len-i-1]即可。

 

用GDB根据coredump文件定位错误

说明:

在程序运行过程中,有时候我们会遇到Segmentfault(段错误)。

这种看起来比较困难,因为没有任何栈、trace信息输出。

这种类型错误往往与指针操作有关,可以通过这种方式进行定位。

名词解说:

coredump又叫做核心转储,当程序运行中发生异常,程序异常退出时,有操作系统把程序当前的内存状况存储在一个core文件中,叫做coredump(Linux如果内存越界会受到SIGSEGV信号,然后就会coredump)。

//core_dump.c

执行结果:

出现段错误,这时可用GDB调试core文件。

说明:

没有产生core文件,原因可能是系统关闭了coredump的功能。

通过ulimit-c或ulimit-a可以查看corefile大小的配置情况。

如果为0,则表示关闭了coredump。

果然是关闭的,解决办法是:

说明:

最对当前的shell进程有效

ulimit-cunlimited:

不限core文件尺寸

ulimit-c2048:

设置core文件最大尺寸为2048blocks(1blocks=512bytes,故2048blicks=1024KB=1MB)

永久有效

在~/.bashrc的最后加入ulimit-cunlimited

用GDB查看core文件

重新执行./core_dump

可见发生了dump,这时执行

#gdb./core_dumpcore

即可定位出发生段错误的位置。

输入bt就可以清楚看出错误是在什么时机产生的。

 

WangYiwei

2013年12月10日

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 人文社科 > 法律资料

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2