gdb

gdb断点设置

启动GDB后，首先就是要设置断点，程序中断后才能调试。在gdb中，断点通常有三种形式：

断点（BreakPoint）：

在代码的指定位置中断，这个是我们用得最多的一种。设置断点的命令是break，它通常有如下方式：

break 在进入指定函数时停住
break 在指定行号停住。
break +/-offset 在当前行号的前面或后面的offset行停住。offiset为自然数。
break filename:linenum 在源文件filename的linenum行处停住。
break … if …可以是上述的参数，condition表示条件，在条件成立时停住。比如在循环境体中，可以设置break if i=100，表示当i为100时停住程序。
可以通过info breakpoints [n]命令查看当前断点信息。此外，还有如下几个配套的常用命令：

delete 删除所有断点
delete breakpoint [n] 删除某个断点
disable breakpoint [n] 禁用某个断点
enable breakpoint [n] 使能某个断点
观察点（WatchPoint）：

在变量读、写或变化时中断，这类方式常用来定位bug。

watch 变量发生变化时中断
rwatch 变量被读时中断
awatch 变量值被读或被写时中断
可以通过info watchpoints [n]命令查看当前观察点信息

捕捉点（CatchPoint）：

捕捉点用来补捉程序运行时的一些事件。如：载入共享库（动态链接库）、C++的异常等。通常也是用来定位bug。

捕捉点的命令格式是：catch ，event可以是下面的内容

throw C++抛出的异常时中断
catch C++捕捉到的异常时中断
exec 调用系统调用exec时（只在某些操作系统下有用）
fork 调用系统调用fork时（只在某些操作系统下有用）
vfork 调用系统调用vfork时（只在某些操作系统下有用）
load 或 load 载入共享库时（只在某些操作系统下有用）
unload 或 unload 卸载共享库时（只在某些操作系统下有用）
另外，还有一个tcatch ，功能类似，不过他只设置一次捕捉点，当程序停住以后，应点被自动删除。

捕捉点信息的查看方式和代码断点的命令是一样的，这里就不多介绍了。

在特定线程中中断

你可以定义你的断点是否在所有的线程上，或是在某个特定的线程。GDB很容易帮你完成这一工作。

break thread
break thread if …
linespec指定了断点设置在的源程序的行号。threadno指定了线程的ID，注意，这个ID是GDB分配的，你可以通过"info threads"命令来查看正在运行程序中的线程信息。如果你不指定thread 则表示你的断点设在所有线程上面。你还可以为某线程指定断点条件。如：

 (gdb) break frik.c:13 thread 28 if bartab > lim

当你的程序被GDB停住时，所有的运行线程都会被停住。这方便你你查看运行程序的总体情况。而在你恢复程序运行时，所有的线程也会被恢复运行。那怕是主进程在被单步调试时。

恢复程序运行和单步调试

在gdb中，和调试步进相关的命令主要有如下几条：

continue 继续运行程序直到下一个断点（类似于VS里的F5）
next 逐过程步进，不会进入子函数（类似VS里的F10）
setp 逐语句步进，会进入子函数（类似VS里的F11）
until 运行至当前语句块结束
finish 运行至函数结束并跳出，并打印函数的返回值（类似VS的Shift+F11）
PS：这些命令大部分可以简写为第一个字母，在日常使用过程中，往往只会输入第一个字符即可执行该命令，我标红的即是通常的使用方式。这几条命令使用非常频繁，并且可以带一些附加参数以实现高级功能，需要熟练掌握。

gdb单步执行和跟踪函数调用

看下面的程序：
#include <stdio.h>
int add_range(int low, int high)
{
int i, sum;
for (i = low; i <= high; i++)
sum = sum + i;
return sum;
}
int main(void)
{
int result[1000];
result[0] = add_range(1, 10);
result[1] = add_range(1, 100);
printf(“result[0]=%d\nresult[1]=%d\n”, result[0], result[1]);
return 0;
}
add_range 函数从 low 加到 high ，在 main 函数中首先从1加到10，把结果保存下来，然后从1加到100，再把结果保存下来，最后打印的两个结果是:

result[0]=55
result[1]=5105
第一个结果正确，第二个结果显然不正确 [1] ，在小学我们就听说过高斯小时候的故事，从1加到100应该是5050。一段代码，第一次运行结果是对的，第二次运行却不对，这是很常见的一类错误现象，这种情况一方面要怀疑代码，另一方面更要怀疑数据：第一次和第二次运行的都是同一段代码，如果代码是错的，那第一次的结果为什么能对呢？所以很可能是第二次运行时相关的状态和数据错了，错误的数据导致了错误的结果。在动手调试之前，读者先试试只看代码能不能看出错误原因，只要前面几章学得扎实就应该能看出来。

[1] 如果你编译运行这个程序的环境和我的环境（Ubuntu 12.04 LTS 32位x86）不同，也许在你的机器上跑不出这个结果，那也没关系，重要的是学会本章介绍的思想方法。另外你也可以尝试修改程序，总有办法得到类似的结果，上例中故意定义了一个很大的数组 result[1000] ，修改数组的大小就会改变各局部变量的存储空间的位置，运行结果就可能会不同。
在编译时要加上 -g 选项，生成的可执行文件才能用 gdb 进行源码级调试:

$ gcc -g main.c -o main
$ gdb main
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright © 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i686-linux-gnu”.
For bug reporting instructions, please see:
http://bugs.launchpad.net/gdb-linaro/…
Reading symbols from /home/akaedu/main…done.
(gdb)
-g 选项的作用是在可执行文件中加入源文件的信息，即可执行文件 main 中的第几条机器指令对应源文件 main.c 的第几行，但并不是把整个源文件嵌入到可执行文件中，所以在调试时必须保证 gdb 能找到源文件 main.c 。 gdb 提供一个类似Shell的命令行环境，上面的 (gdb) 就是提示符，在这个提示符下输入 help 可以查看命令的类别:

(gdb) help
List of classes of commands:

aliases – Aliases of other commands
breakpoints – Making program stop at certain points
data – Examining data
files – Specifying and examining files
internals – Maintenance commands
obscure – Obscure features
running – Running the program
stack – Examining the stack
status – Status inquiries
support – Support facilities
tracepoints – Tracing of program execution without stopping the program
user-defined – User-defined commands

Type “help” followed by a class name for a list of commands in that class.
Type “help all” for the list of all commands.
Type “help” followed by command name for full documentation.
Type “apropos word” to search for commands related to “word”.
Command name abbreviations are allowed if unambiguous.
也可以进一步查看某一类别中有哪些命令，例如查看 files 类别下有哪些命令可用:

(gdb) help files
Specifying and examining files.

List of commands:

add-symbol-file – Load symbols from FILE
add-symbol-file-from-memory – Load the symbols out of memory from a dynamically loaded object file
cd – Set working directory to DIR for debugger and program being debugged
core-file – Use FILE as core dump for examining memory and registers
directory – Add directory DIR to beginning of search path for source files
edit – Edit specified file or function
exec-file – Use FILE as program for getting contents of pure memory
file – Use FILE as program to be debugged
forward-search – Search for regular expression (see regex(3)) from last line listed
generate-core-file – Save a core file with the current state of the debugged process
list – List specified function or line
…
现在试试用 list 命令从第一行开始列出源代码:

(gdb) list 1
1 #include <stdio.h>
2
3 int add_range(int low, int high)
4 {
5 int i, sum;
6 for (i = low; i <= high; i++)
7 sum = sum + i;
8 return sum;
9 }
10
一次只列10行，如果要从第11行开始继续列源代码可以再输入一次:

(gdb) list
也可以什么都不输直接敲回车， gdb 提供了一个很方便的功能，在提示符下直接敲回车表示重复上一条命令:

(gdb) （直接回车）
11 int main(void)
12 {
13 int result[1000];
14 result[0] = add_range(1, 10);
15 result[1] = add_range(1, 100);
16 printf(“result[0]=%d\nresult[1]=%d\n”, result[0], result[1]);
17 return 0;
18 }
gdb 的很多常用命令有简写形式，例如 list 命令可以写成 l ，要列一个函数的源代码也可以用函数名做参数:

(gdb) l add_range
1 #include <stdio.h>
2
3 int add_range(int low, int high)
4 {
5 int i, sum;
6 for (i = low; i <= high; i++)
7 sum = sum + i;
8 return sum;
9 }
10
现在退出 gdb 的环境:

(gdb) quit
我们做一个实验，把源代码改名或移到别处再用 gdb 调试，这样就列不出源代码了:

$ mv main.c mian.c
$ gdb main
…
(gdb) l
5 main.c: No such file or directory.
可见 gcc 的 -g 选项并不是把源代码嵌入到可执行文件中，在调试时也需要源文件。现在把源代码恢复原样，我们继续调试。首先用 start 命令开始执行程序:

$ gdb main
…
(gdb) start
Temporary breakpoint 1 at 0x8048415: file main.c, line 14.
Starting program: /home/akaedu/main

Temporary breakpoint 1, main () at main.c:14
14 result[0] = add_range(1, 10);
(gdb)
gdb 停在 main 函数中变量定义之后的第一条语句处等待我们发命令（ gdb 在提示符之前最后列出的语句总是“即将执行的下一条语句”）。我们可以用 next 命令（简写为 n ）控制这些语句一条一条地执行:

(gdb) n
15 result[1] = add_range(1, 100);
(gdb) （直接回车）
16 printf(“result[0]=%d\nresult[1]=%d\n”, result[0], result[1]);
(gdb) （直接回车）
result[0]=55
result[1]=5105
17 return 0;
用 n 命令依次执行两行赋值语句和一行打印语句，在执行打印语句时结果立刻打出来了，然后停在 return 语句之前等待我们发命令。虽然我们完全控制了程序的执行，但仍然看不出哪里错了，因为错误不在 main 函数中而在 add_range 函数中，现在用 start 命令重新来过，这次用 step命令（简写为 s ）钻进 add_range 函数中去跟踪执行:

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 2 at 0x8048415: file main.c, line 14.
Starting program: /home/akaedu/main

Temporary breakpoint 2, main () at main.c:14
14 result[0] = add_range(1, 10);
(gdb) s
add_range (low=1, high=10) at main.c:6
6 for (i = low; i <= high; i++)
这次停在了 add_range 函数中变量定义之后的第一条语句处。在函数中有几种查看状态的办法， backtrace 命令（简写为 bt ）可以查看函数调用的栈帧：

(gdb) bt #0 add_range (low=1, high=10) at main.c:6 #1 0x08048429 in main () at main.c:14

可见当前的 add_range 函数是被 main 函数调用的， main 传进来的参数是 low=1, high=10 。 main 函数的栈帧编号为1， add_range 的栈帧编号为0。现在可以用 info 命令（简写为 i ）查看 add_range 函数局部变量的值:

(gdb) i locals
i = 0
sum = 0
如果想查看 main 函数当前局部变量的值也可以做到，先用 frame 命令（简写为 f ）选择1号栈帧然后再查看局部变量:

(gdb) f 1
#1 0x08048429 in main () at main.c:14
14 result[0] = add_range(1, 10);
(gdb) i locals
result = {0 <repeats 471 times>, 1184572, 0 <repeats 11 times>, -1207961512, -1073746088, 1249268, -1073745624, 1142336,
…
注意到 result 数组中很多元素的值是杂乱无章的，我们知道未经初始化的局部变量具有不确定的值，到目前为止一切正常。用 s 或 n 往下走几步，然后用 print 命令（简写为 p ）打印出变量 sum 的值:

(gdb) s
7 sum = sum + i;
(gdb) （直接回车）
6 for (i = low; i <= high; i++)
(gdb) （直接回车）
7 sum = sum + i;
(gdb) （直接回车）
6 for (i = low; i <= high; i++)
(gdb) p sum
$1 = 3
第一次循环 i 是1，第二次循环 i 是2，加起来是3，没错。这里的 $1表示gdb保存着这些中间结果，$后面的编号会自动增长，在命令中可以用 $1 、 $2 、 $3 等编号代替相应的值。由于我们本来就知道第一次调用的结果是正确的，再往下跟也没意义了，可以用 finish 命令让程序一直运行到从当前函数返回为止:

(gdb) finish
Run till exit from #0 add_range (low=1, high=10) at main.c:6
0x08048429 in main () at main.c:14
14 result[0] = add_range(1, 10);
Value returned is $2 = 55
返回值是55，当前正准备执行赋值操作，用 n 命令执行赋值操作后查看 result 数组:

(gdb) n
15 result[1] = add_range(1, 100);
(gdb) p result
$3 = {55, 0 <repeats 470 times>, 1184572, 0 <repeats 11 times>, -1207961512, -1073746088, 1249268, -1073745624, 1142336,
…
第一个值55确实赋给了 result 数组的第0个元素。下面用 s 命令进入第二次 add_range 调用，进入之后首先查看参数和局部变量:

(gdb) s
add_range (low=1, high=100) at main.c:6
6 for (i = low; i <= high; i++)
(gdb) bt
#0 add_range (low=1, high=100) at main.c:6
#1 0x08048441 in main () at main.c:15
(gdb) i locals
i = 11
sum = 55
由于局部变量 i 和 sum 没初始化，所以具有不确定的值，又由于两次调用是挨着的， i 和 sum 正好取了上次调用时的值，回顾一下我们讲过的 验证局部变量存储空间的分配和释放 那个例子，其实和现在这个例子是一样的道理，只不过我这次举的例子设法让局部变量 sum 在第一次调用时初值为0而第二次调用时初值不为0。 i 的初值不确定倒没关系，在 for 循环中首先会把 i 赋值为 low ，但 sum 如果初值不是0，累加得到的结果就错了。好了，我们已经找到错误原因，可以退出 gdb 修改源代码了。如果我们不想浪费这次调试机会，可以在 gdb 中马上把 sum 的初值改为0继续运行，看看这一处改了之后还有没有别的Bug:

(gdb) set var sum=0
(gdb) finish
Run till exit from #0 add_range (low=1, high=100) at main.c:6
0x08048441 in main () at main.c:15
15 result[1] = add_range(1, 100);
Value returned is $4 = 5050
(gdb) n
16 printf(“result[0]=%d\nresult[1]=%d\n”, result[0], result[1]);
(gdb) （直接回车）
result[0]=55
result[1]=5050
17 return 0;
这样结果就对了。修改变量的值除了用 set 命令之外也可以用 print 命令，因为 print 命令后面跟的是表达式，而我们知道赋值和函数调用也都是表达式，所以也可以用 print 命令修改变量的值或者调用函数:

(gdb) p result[2]=33
$5 = 33
(gdb) p printf(“result[2]=%d\n”, result[2])
result[2]=33
$6 = 13
我们讲过， printf 的返回值表示实际打印的字符数，所以 $6 的结果是13。最后总结一下本节用到的 gdb 命令：

gdb基本命令1
命令 描述
backtrace（或bt） 查看各级函数调用及参数
finish 连续运行到当前函数返回为止，然后停下来等待命令
frame（或f） 帧编号 选择栈帧
info（或i） locals 查看当前栈帧局部变量的值
list（或l） 列出源代码，接着上次的位置往下列，每次列10行
list 行号 列出从第几行开始的源代码
list 函数名 列出某个函数的源代码
next（或n） 执行下一行语句
print（或p） 打印表达式的值，通过表达式可以修改变量的值或者调用函数
quit（或q） 退出 gdb 调试环境
set var 修改变量的值
start 开始执行程序，停在 main 函数第一行语句前面等待命令
step（或s） 执行下一行语句，如果有函数调用则进入到函数中

gdb调试内存错误

程序在运行一段时间才出错，而且是内存错误。可能是指针访问错误。这种情况下，查找错误比较困难，可以使用core文件帮助查找错误。
$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux

再看看默认的一些参数，注意core file size是个0，程序出错时不会产生core文件了。

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

需要修改参数，才能使出错时产生core文件。

没有找到core文件，我们改改ulimit的设置，让它产生。1024是随便取的，要是core文件大于1024个块，就产生不出来了。

$ ulimit -c 1024 ulimit -c unlimited

$ ulimit -a
core file size (blocks, -c) 1024
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

产生core文件，可以使用gdb调试：

可执行程序是叫做bin(通常core文件就叫做bin.core)，使用下面命令
1.gdb ./bin ./bin.core
2.使用bt命令看frames，假定在n
3.使用frame n调整frame
4.这个时候可以p任何argument或者local variable

调试p string这样的对象的值，可能由于过长，可以p string 的私有成员,如果p arg1.dat，这样可以通过p arg1.dat+100这样进行偏移。

这样获得了这些数据以后，我们可以将这些数据取出来，构造core的条件，单步跟踪，今天我就用这样的方法找到了一个bug。

主要使用到第二条，就可以发现错误出现位置。在core文件内容中，显示的 第一个出现在某个文件的 行数，就为该行出现的错误。仔细查看该行。之后的一些信息就是函数调用的 逐行退出。而且每个都有位置标志。