Linux C——段错误bug的调试

转自:http://blog.chinaunix.NET/space.PHP?uid=317451&do=blog&id=92412

方法一和二适用与像我一样的新手,:-)

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

[cpp]  view plain  copy
  1. dummy_function (void)  
  2. {  
  3.     unsigned char *ptr = 0x00;  
  4.     *ptr = 0x00;  
  5. }  
  6.   
  7. int main (void)  
  8. {  
  9.     dummy_function ();  
  10.     return 0;  
  11. }  
由于上述尝试操作地址为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
Copyright (C) 2006 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 "i686-pc-Linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(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)。

调试步骤:

(1)首先将系统的core文件的大小为无限制,使用命令:ulimit -c unlimited

(2)运行可能会出错的可执行文件,如:./a.out    出错之后可以看到在相应文件夹下面多了“core”文件

(3)产生core文件后,使用gdb命令来进行调试:gdb a.out core

也是一步就定位到了错误所在地,佩服一下Linux/Unix系统的此类设计。
接着考虑下去,以前用windows系统下的ie的时侯,有时打开某些网页,会出现“运行时错误”,这个时侯如果恰好你的机器上又装有windows的编译器的话,他会弹出来一个对话框,问你是否进行调试,如果你选择是,编译器将被打开,并进入调试状态,开始调试。

Linux下如何做到这些呢?我的大脑飞速地旋转着,有了,让它在SIGSEGV的handler中调用gdb,于是第三个方法又诞生了:

3.利用Signal()函数,在段错误SIGSEGV时启动调试:

[cpp]  view plain  copy
  1. #include <stdio.h>  
  2. #include <stdlib.h>  
  3. #include <signal.h>  
  4. #include <string.h>  
  5.   
  6. //信号对应的处理函数  
  7. void dump(int signo)  
  8. {  
  9.     char buf[1024];  
  10.     char cmd[1024];  
  11.     FILE *fh;  
  12.   
  13.     snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());  
  14.     if(!(fh = fopen(buf, "r")))  
  15.         exit(0);  
  16.     if(!fgets(buf, sizeof(buf), fh))  
  17.         exit(0);  
  18.     fclose(fh);  
  19.     if(buf[strlen(buf) - 1] == '\n')  
  20.         buf[strlen(buf) - 1] = '\0';  
  21.     snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());  
  22.     system(cmd);  
  23.   
  24.     exit(0);  
  25. }  
  26.   
  27. void dummy_function (void)  
  28. {  
  29.     unsigned char *ptr = 0x00;  
  30.     *ptr = 0x00;  
  31. }  
  32.   
  33. int main()  
  34. {  
  35.     //定义信号及相关的处理句柄  
  36.     signal(SIGSEGV, &dump);  
  37.     dummy_function ();  
  38.   
  39.     return 0;  
  40. }  
编译运行效果如下:

xiaosuo@gentux test $ gcc -g -rdynamic f.c
xiaosuo@gentux test $ ./a.out
GNU gdb 6.5
Copyright (C) 2006 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2  0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3  0x08048830 in dump (signo=11) at f.c:22
#4  <signal handler called>
#5  0x0804884c in dummy_function () at f.c:31

#6  0x08048886 in main () at f.c:38

怎么样?是不是依旧很酷?

以上方法都是在系统上有gdb的前提下进行的,如果没有呢?其实glibc为我们提供了此类能够dump栈内容的函数簇,详见/usr/include/execinfo.h(这些函数都没有提供man page,难怪我们找不到),另外你也可以通过gnu的手册进行学习。

4.利用backtrace和objdump进行分析:

重写的代码如下:

[cpp]  view plain  copy
  1. #include <execinfo.h>  
  2. #include <stdio.h>  
  3. #include <stdlib.h>  
  4. #include <signal.h>  
  5.   
  6. /* A dummy function to make the backtrace more interesting. */  
  7. void dummy_function (void)  
  8. {  
  9.     unsigned char *ptr = 0x00;  
  10.     *ptr = 0x00;  
  11. }  
  12.   
  13. void dump(int signo)  
  14. {  
  15.     void *array[10];  
  16.     size_t size;  
  17.     char **strings;  
  18.     size_t i;  
  19.   
  20.     size = backtrace (array, 10);  
  21.     strings = backtrace_symbols (array, size);  
  22.           
  23.     printf ("Obtained %zd stack frames.\n", size);  
  24.   
  25.     for (i = 0; i < size; i++)  
  26.         printf ("%s\n", strings[i]);  
  27.   
  28.     free (strings);  
  29.       
  30.     exit(0);  
  31. }  
  32.   
  33. int main()  
  34. {  
  35.     signal(SIGSEGV, &dump);  
  36.     dummy_function();  
  37.   
  38.     return 0;  
  39. }  
编译运行结果如下:

xiaosuo@gentux test $ gcc -g -rdynamic g.c
xiaosuo@gentux test $ ./a.out
Obtained 5 stack frames.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]

这次你可能有些失望,似乎没能给出足够的信息来标示错误,不急,先看看能分析出来什么吧,用objdump反汇编程序,找到地址0x804876f对应的代码位置:

xiaosuo@gentux test $ objdump -d a.out

8048765:       e8 02 fe ff ff          call   804856c <signal@plt>
 804876a:       e8 25 ff ff ff          call   8048694 <dummy_function>
 804876f:       b8 00 00 00 00          mov    $0x0,%eax
 8048774:       c9                      leave

我们还是找到了在哪个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!

后记:

本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
linux段错误(Segmentation Fault)是指程序访问了不属于它的内存空间,或者访问了已经释放的内存空间,造成了程序运行错误。解决该问题可以按照以下步骤进行: 1. 检查程序代码:首先检查代码中是否存在指针操作错误、数组越界、内存泄漏等bug。特别注意函数调用和内存操作的正确性。 2. 添加调试信息:在程序中加入适当的调试信息,以便于定位问题所在。可以通过输出程序运行过程中的变量值以及各个关键节点的提示信息来帮助定位错误。 3. 使用调试工具:可以使用诸如gdb等调试工具来定位问题。将程序运行在调试模式下,可以在程序段错误发生时进入调试器,查看内存情况,并通过回溯调用栈找到导致错误的具体代码。 4. 内存泄漏检测工具:使用内存泄漏检测工具(如Valgrind)来帮助找到程序中的内存泄漏问题。 5. 动态分析工具:利用动态分析工具(如strace、ltrace)来追踪程序在运行时的系统调用和库函数调用,帮助发现可能导致段错误的问题。 6. 逐步重构代码:根据对程序的调试分析结果,逐步重构代码,修复错误,确保程序的访问内存操作都是合法的。 7. 规范化编程:在编程过程中遵循规范,严格按照函数定义和内存操作原则进行编码,规避潜在的段错误问题。 总之,解决Linux段错误要通过分析代码、使用调试工具和注意内存操作规范等方式来定位和修复问题。需要强调的是,在调试过程中需要耐心和细致,同时也需要严格遵循编程规范,以避免出现段错误问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值