Linux程序调试

标签: linux 程序 调试 | 发表时间:2013-07-13 12:18 | 作者:C++技术中心
出处:http://www.cppblog.com/
Linux下的段错误产生的原因及调试方法

   原文地址: http://www.upsdn.net/html/2006-11/775.html 
   参考地址: http://www.cnblogs.com/khler/archive/2010/09/16/1828349.html 

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

一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来保存的,他是一个48位的寄存器,其中的32位是保存由它指向的gdt表,后13位保存相应于gdt的下标,最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表,在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访问,cpu就会产生相应的异常保护,于是segmentation fault就出现了.

在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的

1)访问系统数据区,尤其是往  系统保护的内存地址写数据
   最常见就是给一个指针以0地址
2)内存越界(数组越界,变量类型不一致等) 访问到不属于你的内存区域

解决方法

我们在用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
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)。不过奇怪了,我的系统上并没有找到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
段错误 (core dumped)
xiaosuo@gentux test $ ls
a.out  core  d.c  f.c  g.c  pango.c  test_iconv.c  test_regex.c
core文件终于产生了,用gdb调试一下看看吧:
xiaosuo@gentux test $ gdb ./a.out core
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".


warning: Can't read pathname for load map: 输入/输出错误.
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
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x08048524 in dummy_function () at d.c:4
4               *ptr = 0x00;
哇,好历害,还是一步就定位到了错误所在地,佩服一下Linux/Unix系统的此类设计。
接着考虑下去,以前用windows系统下的ie的时侯,有时打开某些网页,会出现“运行时错误”,这个时侯如果恰好你的机器上又装有windows的编译器的话,他会弹出来一个对话框,问你是否进行调试,如果你选择是,编译器将被打开,并进入调试状态,开始调试。
Linux下如何做到这些呢?我的大脑飞速地旋转着,有了,让它在SIGSEGV的handler中调用gdb,于是第三个方法又诞生了:
3.段错误时启动调试:
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>

void dump(int signo)
{
        char buf[1024];
        char cmd[1024];
        FILE *fh;

        snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
        if(!(fh = fopen(buf, "r")))
                exit(0);
        if(!fgets(buf, sizeof(buf), fh))
                exit(0);
        fclose(fh);
        if(buf[strlen(buf) - 1] == '\n')
                buf[strlen(buf) - 1] = '\0';
        snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());
        system(cmd);

        exit(0);
}

        void
dummy_function (void)
{
        unsigned char *ptr = 0x00;
        *ptr = 0x00;
}

        int
main (void)
{
        signal(SIGSEGV, &dump);
        dummy_function ();

        return 0;
}
编译运行效果如下:
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进行分析:
重写的代码如下:
#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

/* A dummy function to make the backtrace more interesting. */
        void
dummy_function (void)
{
        unsigned char *ptr = 0x00;
        *ptr = 0x00;
}

void dump(int signo)
{
        void *array[10];
        size_t size;
        char **strings;
        size_t i;

        size = backtrace (array, 10);
        strings = backtrace_symbols (array, size);

        printf ("Obtained %zd stack frames.\n", size);

        for (i = 0; i < size; i++)
                printf ("%s\n", strings[i]);

        free (strings);

        exit(0);
}

        int
main (void)
{
        signal(SIGSEGV, &dump);
        dummy_function ();

        return 0;
}
编译运行结果如下:
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)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记:
本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。

部分资料来源于xiaosuo @ cnblog.cn, 特此致谢

作者:upsdn整理   更新日期:2006-11-03
来源:upsdn.net   浏览次数:



其它调试办法

  • 添加日志 

            在Linux上的使用开源C++日志库---log4cplus  



linux下追踪函数调用堆栈

一般察看函数运行时堆栈的方法是使用GDB之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的。

 在头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈

 Function: int backtrace(void **buffer,int size)

 该函数用与获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小

 在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址

 注意某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架;删除框架指针也会使无法正确解析堆栈内容

 Function: char ** backtrace_symbols (void *const *buffer, int size)

 backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的数组指针,size是该数组中的元素个数(backtrace的返回值)

 函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名,函数的偏移地址,和实际的返回地址

 现在,只有使用ELF二进制格式的程序和苦衷才能获取函数名称和偏移地址.在其他系统,只有16进制的返回地址能被获取.另外,你可能需要传递相应的标志给链接器,以能支持函数名功能(比如,在使用GNU ld的系统中,你需要传递(-rdynamic))

 该函数的返回值是通过malloc函数申请的空间,因此调用这必须使用free函数来释放指针.

 注意:如果不能为字符串获取足够的空间函数的返回值将会为NULL

 Function:void backtrace_symbols_fd (void *const *buffer, int size, int fd)

 backtrace_symbols_fd与backtrace_symbols 函数具有相同的功能,不同的是它不会给调用者返回字符串数组,而是将结果写入文件描述符为fd的文件中,每个函数对应一行.它不需要调用malloc函数,因此适用于有可能调用该函数会失败的情况。

#include <execinfo.h> 
#include <stdio.h> 
#include <stdlib.h> 

/* Obtain a backtrace and print it to stdout. */ 
void print_trace (void) 

        void *array[10]; 
        size_t size; 
        char **strings; 
        size_t i; 

        size = backtrace (array, 10); 
        strings = backtrace_symbols (array, size); 

        printf ("Obtained %zd stack frames.\n", size); 

        for (i = 0; i < size; i++) 
                printf ("%s\n", strings[i]); 

        free (strings); 


/* A dummy function to make the backtrace more interesting. */ 
void dummy_function (void) 

        print_trace (); 


int main (void) 

        dummy_function (); 
        return 0; 
}
编译运行的结果如下:
# gcc bt.c -rdynamic -o bt
# ./bt
Obtained 5 stack frames.
./bt(_Z11print_tracev+0x19) [0x804870d]
./bt(_Z14dummy_functionv+0xb) [0x8048779]
./bt(main+0x16) [0x8048792]
/lib/libc.so.6(__libc_start_main+0xdc) [0x116e9c]
./bt(__gxx_personality_v0+0x31) [0x8048641]


注: addr2line - convert addresses into file names and line numbers.



C++技术中心 2013-07-13 20:18 发表评论

相关 [linux 程序 调试] 推荐:

Linux程序调试

- - C++博客-首页原创精华区
Linux下的段错误产生的原因及调试方法    原文地址: http://www.upsdn.net/html/2006-11/775.html .    参考地址: http://www.cnblogs.com/khler/archive/2010/09/16/1828349.html .

Linux下gdb调试

- - CSDN博客移动开发推荐文章
关于gdb的其他客套话不多说,直接进入正题. 列出产生执行文件源代码的一部分. 执行一行源代码但不进入函数内部. 执行一行源代码而且进入函数内部. 监视一个变量的值,一旦值有变化程序停住. 1.新建一个源文件vi yrp.cc,源代码如下:. 2.生成可执行文件 g++ -g -o yrp yrp.cc  注意必须使用-g参数,编译会加入调试信息,否则无法调试执行文件..

Linux下进行GDB调试

- - CSDN博客推荐文章
GDB是GNU开源组织发布的一个强大的UNIX下的程序调试工具. 一般来说,GDB主要帮助自己完成下面四个方面的功能;. 1:启动你的程序,可以按照你的自定义的要求随心所欲的运行程序. 2:可以让被调试的程序在你所指定的调制的断点处停住(断点可以是条件表达式). 3:当程序被停住时,可以检查你的程序中发生的事.

加速Linux程序编译

- jin - 李凡希的Blog
  项目越来越大,每次需要重新编译整个项目都是一件很浪费时间的事情. Research了一下,找到以下可以帮助提高速度的方法,总结一下.   有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟,也许这个数字是有点夸张了,不过粗想想,把文件放到内存上做编译应该是比在磁盘上快多了吧,尤其如果编译器需要生成很多临时文件的话.

Linux下gdb调试工具的使用

- - CSDN博客综合推荐文章
gdb是GNU开源组织发布的一个强大的Linux下的程序调试工具. gdb主要完成四个方面的功能:(1)、启动你的程序,可以按照你的自定义的要求随心所欲的运行程序;(2)、可让被调试的程序在你所指定的调试的断点处停住(断点可以是条件表达式);(3)、当程序被停住时,可以检查此时你的程序中所发生的事;(4)、动态的改变你程序的执行环境.

Linux下第一个驱动程序

- ziche - CSDN博客推荐文章
        因为在Ubuntu环境下写的文章和做的实验,没有安装linux下比较好用的截图工具,所以没有附带太多截屏,还望海涵,不过该描述的都到位了.        曾经还一直处于应用程序开发的我,以为驱动开发者是那么的厉害,以为只有牛人才能走到这一步,随着知识的积累,发现并非如此,驱动开发并不像想象中那么特别,俗话说术业有专攻,开发者只是使用的工具不同,且从事的领域不同,产品不同罢了.

Android调试程序技巧

- - ITeye博客
在开发的过程中我们经常需要调试程序的执行路径,如我们想知道一个Activity的生命周期方法的调用顺序,我们可能会写如下代码. 这样每次都要输入两个参数,有没有更简便的方法呢. 我们可以通过Thread.currentThread().getStackTrace()获取当前堆栈调用信息,从堆栈信息中可以获取当前调用的java文件名,类名,方法名和代码行号.

用gdb+nm调试php c extension程序

- ndv - 淘宝核心系统团队博客
最近在写Beanstalkd的php c extension客户端程序,写程序离不开调试,下面把调试中碰到的问题和解决方法和大家分享一下. .so写好了是给php脚本调用的,如果php脚本执行崩掉了,.so也只能在进程中饮恨而终,这时候php脚本调试经常用的echo, print_r, var_dump都派不上用场了.

调试JavaScript脚本程序(Firefox篇)

- - JavaScript - Web前端 - ITeye博客
试Firefox里面的脚本需要安装一个插件Venkman:. 1.       启动Firefox,浏览页面. 2.       点击“Add to firefox”,重启Firefox就可以使用了. 先简单地介绍一下如何在Venkman里面设置断点和查看变量的值. 1.       启动Firefox,运行网页到test.html.

Go程序调试、分析与优化

- - Tony Bai
Brad Fitzpatrick在 YAPC Asia 2015(Yet Another Perl Conference)上做了一次技术分享,题为:" Go Debugging, Profiling, and Optimization". 个人感觉这篇分享中价值最大的是BradFitz现场演示的一个有关如果对 Go程序进行调试、分析和优化的 Demo,Brad将demo上传到了他个人在github.com的 repo中,但不知为何,repo中的代码似乎与repo里talk.md中的说明不甚一致(btw,我并没有看video).