Gdb+core调试技术

最新推荐文章于 2023-07-13 15:37:23 发布

RunBoying

最新推荐文章于 2023-07-13 15:37:23 发布

阅读量1.5k

点赞数

分类专栏：开发工具使用心得 Linux命令文章标签： freebsd signal suse bt gcc crash

Linux命令同时被 2 个专栏收录

100 篇文章 1 订阅

订阅专栏

开发工具使用心得

71 篇文章 0 订阅

订阅专栏

转载自：

http://zhwen.org/xlog/?p=453

做c方面的开发，免不了要是用gdb来调试程序，最近也是在公司做的时候时常需要使用gdb来分析程序，使用最多的当属使用core来查看程序运行的crash原因。

在linux中应用程序运行奔溃之后一般会产生core文件，core文件是core dump来产生，core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中。

要生成core dump文件，首先要在系统中设置core文件大小的上限，超过这个上限的core文件就不生成了，而一般系统的设置是0，即不生成core文件，所以要先修改这个上限值，设置如下：

1. 系统设置

使用ulimit -a命令查看系统所有限制情况，

helight@zhwen:~> ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 3583
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 3583
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
helight@zhwen:~>

使用ulimit -c ***来设置core文件大小的上限。一般使用ulimit -c unlimited即不限制core文件大小。

helight@zhwen:~> ulimit -c unlimited
helight@zhwen:~> ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 3583
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 3583
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
helight@zhwen:~>

2. 编译程序

当然另外一个就是要是用gdb来调试程序，那编译的时候加入-g参数就是必不可少的，

下面是我在调试一个线程程序时的情况：

helight@zhwen:~/test> g++ -g test.cpp -o test -lpthread
helight@zhwen:~/test> ./test
This is the main process.
This is the main process.
This is the main process.
This is a pthread.
This is a pthread.
This is a pthread.
Segmentation fault (core dumped)
helight@zhwen:~/test> ls
core.314 test test.cpp
helight@zhwen:~/test>

3. 使用gdb+core调试：

helight@zhwen:~/test> gdb ./test ./core.314
GNU gdb (GDB) SUSE (6.8.50.20090302-1.5.18)
....

启动调试可以使用where或者bt（breaktrace）来查看错误发生的位置和堆栈。

...
Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0 0x080486bd in xthread (args=0x0) at test.cpp:17
17 printf("yyyyyyyyy%ld \n",*xy);
(gdb) bt
#0 0x080486bd in xthread (args=0x0) at test.cpp:17
#1 0xb7ee535b in start_thread () from /lib/libpthread.so.0
#2 0xb7d5dc0e in clone () from /lib/libc.so.6
(gdb)

在gdb的调试中还可以使用一下的一些命令来辅助调试：

search fun_name 查找函数

b fun_name在这个函数处设置断点

b file.c 114 在file.c这个文件的114行设置断点

info break或者info b来查看当前设置断点的情况

run 运行程序

file 加载二进制文件

n执行下一语句

s单步执行

c继续运行

p name 打印变量

q退出

上述代码例子没有给出，下面从这里转载个代码

http://topic.csdn.net/u/20091028/23/b5a8884a-778f-4535-8779-ae6453ada88e.html

$ more foo.c

#include  

static void sub(void);

int main(void)
{
  sub();
  return 0;
}

static void sub(void)
{
  int *p = NULL;

  /* derefernce a null pointer, expect core dump. */
  printf("%d", *p);
}

$ gcc -Wall -g foo.c
$ ./a.out
Segmentation fault

$ ls -l core.*
ls: core.*: No such file or directory

今天有人问起这个问题，于是写了个简单的例子，演示一下这个过程。FreeBSD的开发者手册上对此有专节论述，此外也可以参考gdb手册。
编写一个小程序：
CODE:

1   void foo(void)
2   {
3       *(int *)0 = 1;
4   }
5
6   int main(void)
7   {
8       foo();
9   }
命名为foo.c，使用-g选项编译它，以便能够在core文件中包含调试信息，方便gdb跟踪至源代码行：
CODE:

gcc -g foo.c
生成的文件名就是默认的a.out。
运行这个a.out程序，显然，它会在第三行处产生一个core dump，生成a.out.core文件。
我们这时就可以使用下述命令对其进行分析：
CODE:

gdb a.out a.out.core
运行结果如下：
CODE:

[~]$gdb a.out a.out.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 foo () at foo.c:3
3 *(int *)0 = 1;
(gdb)
我们可以看到，这时gdb已经打印出了程序崩溃原因，以及出错的代码行位置。
如果我们想查看出问题之前的调用栈，可以使用gdb的bt命令：
CODE:

(gdb) bt
#0 foo () at foo.c:3
#1 0x080484bd in main () at foo.c:8
(gdb)
我们还可以使用up和down命令在调用栈中移动，并检查相应栈内的变量值，以便分析（复杂）程序出错的真实原因。
http://bbs.chinaunix.net/viewthread.php?tid=753996&extra=page%3D1