Linux下的段错误调试方法

转自http://wenku.baidu.com/view/7416d23710661ed9ad51f33f .html

1. 执行socket文件时，出现段错误 (core dumped)

产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址.

解决方法：

利用gdb逐步查找段错误:

首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:
   1、 gcc -g -rdynamic d.c
   2、 gdb ./a.out
   3、 r
这样就找到了出错位置。然后在相应位置修改。

2. linux 段错误 如何调试

 linux下的c程序常常会因为内存访问错误等原因造成segment fault（段错误）此时如果系统core dump功能是打开的，那么将会有内存映像转储到硬盘上来，之后可以用gdb对core文件进行分析，还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。

    使用ulimit -a可以查看系统core文件的大小限制；使用ulimit -c [kbytes]可以设置系统允许生成的core文件大小。

ulimit -c 0 不产生core文件
ulimit -c 100 设置core文件最大为100k

ulimit -c unlimited 不限制core文件大小

步骤：

1、当发生段错误时，我们查看ulimit -a  （core file size (blocks, -c) 0）并没有文件， 

2、设置 ：ulimit -c unlimited   不限制core文件大小

3.、运行程序 ，发生段错误时会自动记录在core中

4、test]$ ls -al core.* 在那个文件下（-rw------- 1 leconte leconte 139264 01-06 22:3 1 core.2065）

5、使用gdb 运行程序和段错误记录的文件。（est]$ gdb ./test core.2065）

6、会提哪行有错。

     很多系统默认的core文件大小都是0，我们可以通过在Shell的启动脚本/etc/bashrc或者~/.bashrc等地方来加入 ulimit -c 命令来指定core文件大小，从而确保core文件能够生成。

除此之外，还可以在/proc/sys/kernel/core_pattern里设置core文件的文件名模板，详情请看core的官方man手册。

3. 段错误bug的调试

我们在用C/C++语言写程序的时侯，内存管理的绝大部分工作都是需要我们来做的。实际上，内存管理是一个比较繁琐的工作，无论你多高明，经验多丰富，难免会在此处犯些小错误，而通常这些错误又是那么的浅显而易于消除。但是手工“除虫”（debug），往往是效率低下且让人厌烦的，本文将就"段错误"这个内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。

下面将就以下的一个存在段错误的程序介绍几种调试方法：

1 dummy_function (void)

2 {

3 unsigned char *ptr = 0x00;

4 *ptr = 0x00;

5 }

6

7 int main (void)

8 {

9 dummy_function ();

10

11 return 0;

12 }

作为一个熟练的C/C++程序员，以上代码的bug应该是很清楚的，因为它尝试操作地址为0的内存区域，而这个内存区域通常是不可访问的禁区，当然就会出错了。我们尝试编译运行它:

xiaosuo@gentux test $ ./a.out

段错误

果然不出所料，它出错并退出了。

1.利用gdb逐步查找段错误:

这种方法也是被大众所熟知并广泛采用的方法，首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:

xiaosuo@gentux test $ gcc -g -rdynamic d.c

xiaosuo@gentux test $ gdb ./a.out

GNU gdb 6.5

……

(gdb) r

Starting program: /home/xiaosuo/test/a.out

Program received signal SIGSEGV, Segmentation fault.

0x08048524 in dummy_function () at d.c:4

4 *ptr = 0x00;

(gdb)

哦？！好像不用一步步调试我们就找到了出错位置d.c文件的第4行，其实就是如此的简单。

从这里我们还发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man 7 signal)，我们知道SIGSEGV默认handler的动作是打印”段错误"的出错信息，并产生Core文件，由此我们又产生了方法二。

2.分析Core文件：

Core文件是什么呢？

The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory at the time of termination. A list of the signals which cause a process to dump core can be found in signal(7).

以上资料摘自man page(man 5 core)。不过奇怪了，我的系统上并没有找到core文件。后来，忆起为了渐少系统上的拉圾文件的数量（本人有些洁癖，这也是我喜欢Gentoo的原因之一），禁止了core文件的生成，查看了以下果真如此，将系统的core文件的大小限制在512K大小，再试:

xiaosuo@gentux test $ ulimit -c

0

xiaosuo@gentux test $ ulimit -c 1000

xiaosuo@gentux test $ ulimit -c

1000

xiaosuo@gentux test $ ./a.out

段错误 <