精华内容
下载资源
问答
  • 段错误产生的原因

    万次阅读 2015-09-27 22:13:31
    段错误产生的原因  1 访问不存在的内存地址  复制代码代码如下: #include  #include  void main()  {  int *ptr = NULL;  *ptr = 0;  }  2 访问系统保护的内存地址  复制代码代码如下: #include ...

    段错误是指程序尝试访问一段不可访问的内存。

    在类Unix系统中,当出现段错误时,系统发送信号量SIGSEGV给产生段错误的进程;在Windows系统中,系统会发送异常STATUS_ACCESS_VIOLATION给产生段错误的进程。

    产生段错误的原因

    程序运行过程中能访问到的内存空间主要有栈和堆。栈存放了函数的本地变量,堆是程序运行过程中能够自由分配和使用的内存空间。产生段错误和栈、堆的访问密切相关。

    产生段错误的原因主要有:

    • 解引用空指针
    • 访问不可访问的内存空间(如内核空间)
    • 访问不存在的内存地址
    • 试图写一个只读内存空间(如代码段)
    • 栈溢出(函数递归调用)
    • 使用未初始化的指针(定义时没有初始化或者已经回收)

    避免段错误

    • 定义指针后初始化
    • 数组下标是否越界
    • 在堆上分配空间是否足够(内存限制)
    • 变量处理时格式控制是否合理


    注意事项:

    1、出现段错误时,首先应该想到段错误的定义,从它出发考虑引发错误的原因。

    2、在使用指针时,定义了指针后记得初始化指针,在使用的时候记得判断是否为NULL。

    3、在使用数组时,注意数组是否被初始化,数组下标是否越界,数组元素是否存在等。

    4、在访问变量时,注意变量所占地址空间是否已经被程序释放掉。

    5、在处理变量时,注意变量的格式控制是否合理等。


    段错误产生的原因 

    1 访问不存在的内存地址 
    复制代码代码如下:

    #include<stdio.h> 
    #include<stdlib.h> 
    void main() 

    int *ptr = NULL; 
    *ptr = 0; 


    2 访问系统保护的内存地址 
    复制代码代码如下:

    #include<stdio.h> 
    #include<stdlib.h> 
    void main() 

    int *ptr = (int *)0; 
    *ptr = 100; 


    3 访问只读的内存地址 
    复制代码代码如下:

    #include<stdio.h> 
    #include<stdlib.h> 
    #include<string.h> 
    void main() 

    char *ptr = "test"; 
    strcpy(ptr, "TEST"); 


    4 栈溢出 
    复制代码代码如下:

    #include<stdio.h> 
    #include<stdlib.h> 
    void main() 

    main(); 
    展开全文
  • 段错误

    千次阅读 2017-08-15 14:11:01
    一、什么是段错误? 一旦一个程序发生了越界访问,cpu 就会产生相应的保护,于是 ...二、段错误产生的原因 下面是一些典型的段错误原因: 非关联化空指针——这是特殊情况由内存管理硬件 试图访

    一、什么是段错误?

    一旦一个程序发生了越界访问,cpu 就会产生相应的保护,于是 segmentation fault 就出现了,通过上面的解释,段错误应该就是访问了不可访问的内存,这个内存区要么是不存在的,要么是受到系统保护的,还有可能是缺少文件或者文件损坏。

    二、段错误产生的原因

    下面是一些典型的段错误的原因:
    非关联化空指针——这是特殊情况由内存管理硬件
    试图访问一个不存在的内存地址(在进程的地址空间)
    试图访问内存的程序没有权利(如内核结构流程上下文)
    试图写入只读存储器(如代码段)

    1、访问不存在的内存地址

    在C代码,分割错误通常发生由于指针的错误使用,特别是在C动态内存分配。非关联化一个空指针总是导致段错误,但野指针和悬空指针指向的内存,可能会或可能不会存在,而且可能或不可能是可读的还是可写的,因此会导致瞬态错误。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = NULL;  
    6.     *ptr = 0;  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  

    现在,非关联化这些变量可能导致段错误:非关联化空指针通常会导致段错误,阅读时从野指针可能导致随机数据但没有段错误,和阅读从悬空指针可能导致有效数据,然后随机数据覆盖。

    2、访问系统保护的内存地址 

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = (int *)0;  
    6.     *ptr = 100;  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  

    3、访问只读的内存地址

    写入只读存储器提出了一个 segmentation fault,这个发生在程序写入自己的一部分代码段或者是只读的数据段,这些都是由操作系统加载到只读存储器。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2. #include <string.h>  
    3.   
    4. int main (void)  
    5. {  
    6.     char *ptr = "test";  
    7.     strcpy (ptr, "TEST");  
    8.     return 0;  
    9. }  
    10. 输出结果:  
    11. 段错误(核心已转储)  

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     char *ptr = "hello";  
    6.     *ptr = 'H';  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  
    上述例子ANSI C代码通常会导致段错误和内存保护平台。它试图修改一个字符串文字,这是根据ANSI C标准未定义的行为。大多数编译器在编译时不会抓,而是编译这个可执行代码,将崩溃。

    包含这个代码被编译程序时,字符串“hello”位于rodata部分程序的可执行文件的只读部分数据段。当加载时,操作系统与其他字符串和地方常数只读段的内存中的数据。当执行时,一个变量 ptr 设置为指向字符串的位置,并试图编写一个H字符通过变量进入内存,导致段错误。编译程序的编译器不检查作业的只读的位置在编译时,和运行类unix操作系统产生以下运行时发生 segmentation fault。

    可以纠正这个代码使用一个数组而不是一个字符指针,这个栈上分配内存并初始化字符串的值:

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     char ptr[] = "hello";  
    6.     ptr[0] = 'H';  
    7.     return 0;  
    8. }  

    即使不能修改字符串(相反,这在C标准未定义行为),在C char *类型,所以没有隐式转换原始代码,在c++的 const char *类型,因此有一个隐式转换,所以编译器通常会抓住这个特定的错误。

    4、空指针废弃

    因为是一个很常见的程序错误空指针废弃(读或写在一个空指针,用于C的意思是“没有对象指针”作为一个错误指示器),大多数操作系统内存访问空指针的地址,这样它会导致段错误。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = NULL;  
    6.     printf ("%d\n", *ptr);  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  
    这个示例代码创建了一个空指针,然后试图访问它的值(读值)。在运行时在许多操作系统中,这样做会导致段错误。

    非关联化一个空指针,然后分配(写一个值到一个不存在的目标)也通常会导致段错误。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = NULL;  
    6.     *ptr = 1;  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  
    下面的代码包含一个空指针,但当编译通常不会导致段错误,值是未使用的。因此,废弃通常会被优化掉,死代码消除。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = NULL;  
    6.     *ptr;  
    7.     return 0;  
    8. }  

    还有,比如malloc 动态分配内存,释放、置空完成后,不可再使用该指针。

    [cpp] view plain copy
    1. #include <stdio.h>  
    2. #include <stdlib.h>  
    3. #include <string.h>  
    4.   
    5. int main()  
    6. {  
    7.     char* str=(char* )malloc(100);  
    8.     if(*str)  
    9.     {  
    10.         return;   
    11.     }  
    12.     strcpy(str,"hello");  
    13.     printf("%s\n",str);  
    14.     free(str);  
    15.     str=NULL;  
    16.     strcpy(str,"abcdef");  
    17.     return 0;  
    18. }  
    19. 输出结果:  
    20. hello  
    21. 段错误 (核心已转储)<strong>  
    22. </strong>  

    5、堆栈溢出

    [cpp] view plain copy
    1. #include <stdio.h>  
    2. #include <string.h>  
    3.   
    4. int main (void)  
    5. {  
    6.     main ();  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  

    上述例子的无限递归,导致的堆栈溢出会导致段错误,但无线递归未必导致堆栈溢出,优化执行的编译器和代码的确切结构。在这种情况下,遥不可及的代码(返回语句)行为是未定义的。因此,编译器可以消除它,使用尾部调用优化,可能导致没有堆栈使用。其他优化可能包括将递归转换成迭代,给出例子的结构功能永远会导致程序运行,虽然可能不是其他堆栈溢出。

    6、内存越界(数组越界,变量类型不一致等)

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     char test[10];  
    6.     printf ("%c\n", test[100000]);  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  

    三、段错误信息的获取

    程序发生段错误时,提示信息很少,下面有几种查看段错误的发生信息的途径。

    1、dmesg

    dmesg 可以在应用程序崩溃时,显示内存中保存的相关信息。如下所示,通过 dmesg 命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。

    [cpp] view plain copy
    1. root@#dmesg  
    2. [ 6357.422282] a.out[3044]: segfault at 806851c ip b75cd668 sp bf8b2100 error 4 in libc-2.15.so[b7559000+19f000]  
    2、-g

    使用gcc编译程序的源码时,加上 -g 参数,这样可以使得生成的二进制文件中加入可以用于 gdb 调试的有用信息。

    参看:C语言再学习 -- GCC编译过程

    可产生供gdb调试用的可执行文件,大小明显比只用-o选项编译汇编连接后的文件大。

    [cpp] view plain copy
     
     在CODE上查看代码片派生到我的代码片
    1. root@ubuntu:/home/tarena/project/c_test# gcc hello.c   
    2. root@ubuntu:/home/tarena/project/c_test# ls -la a.out   
    3. -rwxr-xr-x 1 root root 7159 Nov 26 23:32 a.out  
    4. root@ubuntu:/home/tarena/project/c_test# gcc -g hello.c   
    5. root@ubuntu:/home/tarena/project/c_test# ls -la a.out   
    6. -rwxr-xr-x 1 root root 8051 Nov 26 23:32 a.out  

    gdb的简单使用:

    (gdb)l  列表(list)
    (gdb)r  执行(run)
    (gdb)n  下一个(next)
    (gdb)q  退出(quit)
    (gdb)p  输出(print)
    (gdb)c  继续(continue)
    (gdb)b 4 设置断点(break)
    (gdb)d   删除断点(delete)

    [cpp] view plain copy
     
     在CODE上查看代码片派生到我的代码片
    1. root@ubuntu:/home/tarena/project/c_test# gdb a.out  
    2. GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02  
    3. Copyright (C) 2012 Free Software Foundation, Inc.  
    4. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>  
    5. This is free software: you are free to change and redistribute it.  
    6. There is NO WARRANTY, to the extent permitted by law.  Type "show copying"  
    7. and "show warranty" for details.  
    8. This GDB was configured as "i686-linux-gnu".  
    9. For bug reporting instructions, please see:  
    10. <http://bugs.launchpad.net/gdb-linaro/>...  
    11. Reading symbols from /home/tarena/project/c_test/a.out...done.  
    12. (gdb) l  
    13. 1   #include <stdio.h>  
    14. 2   int main (void)  
    15. 3   {  
    16. 4       printf ("hello world!\n");  
    17. 5       return 0;  
    18. 6   }  
    19. (gdb) r  
    20. Starting program: /home/tarena/project/c_test/a.out   
    21. hello world!  
    22. [Inferior 1 (process 6906) exited normally]  
    23. (gdb) q  
    24. root@ubuntu:/home/tarena/project/c_test#   

    3、nm

    使用 nm 命令列出二进制文件中符号表,包括符号地址、符号类型、符号名等。这样可以帮助定位在哪里发生了段错误。

    [cpp] view plain copy
    1. root@# nm a.out   
    2. 08049f28 d _DYNAMIC  
    3. 08049ff4 d _GLOBAL_OFFSET_TABLE_  
    4. 080484ac R _IO_stdin_used  
    5.          w _Jv_RegisterClasses  
    6. 08049f18 d __CTOR_END__  
    7. 08049f14 d __CTOR_LIST__  
    8. 08049f20 D __DTOR_END__  
    9. 08049f1c d __DTOR_LIST__  
    10. 080485a4 r __FRAME_END__  
    11. 08049f24 d __JCR_END__  
    12. 08049f24 d __JCR_LIST__  
    13. 0804a010 A __bss_start  
    14. 0804a008 D __data_start  
    15. 08048460 t __do_global_ctors_aux  
    16. 08048330 t __do_global_dtors_aux  
    17. 0804a00c D __dso_handle  
    18.          w __gmon_start__  
    19. 08048452 T __i686.get_pc_thunk.bx  
    20. 08049f14 d __init_array_end  
    21. 08049f14 d __init_array_start  
    22. 08048450 T __libc_csu_fini  
    23. 080483e0 T __libc_csu_init  
    24.          U __libc_start_main@@GLIBC_2.0  
    25. 0804a010 A _edata  
    26. 0804a018 A _end  
    27. 0804848c T _fini  
    28. 080484a8 R _fp_hw  
    29. 08048294 T _init  
    30. 08048300 T _start  
    31. 0804a010 b completed.6159  
    32. 0804a008 W data_start  
    33. 0804a014 b dtor_idx.6161  
    34. 08048390 t frame_dummy  
    35. 080483b4 T main  
    4、ldd

    使用 ldd 命令查看二进制程序的共享链接库依赖,包括库的名称、起始地址,这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。

    [cpp] view plain copy
    1. root@t# ldd a.out   
    2.     linux-gate.so.1 =>  (0xb7765000)  
    3.     libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75ac000)  
    4.     /lib/ld-linux.so.2 (0xb7766000)  


    四、段错误的调试方法

    接下来的讲解是围绕下面的代码进行的:

    [cpp] view plain copy
    1. #include <stdio.h>  
    2.   
    3. int main (void)  
    4. {  
    5.     int *ptr = NULL;  
    6.     *ptr = 10;  
    7.     return 0;  
    8. }  
    9. 输出结果:  
    10. 段错误(核心已转储)  

    1、使用 printf 输出信息

    这个是看似最简单,但往往很多情况下十分有效的调试方式,也许可以说是程序员用的最多的调试方式。简单来说,就是在程序的重要代码附近加上像 printf 这类输出信息,这样可以跟踪并打印出段错误在代码中可能出现的位置。

    为了方便使用这种方法,可以使用条件编译指令 #define DEBUG 和 #endif 把 printf 函数包起来。这样在程序编译时,如果加上 -DDEBUG 参数就可以查看调试信息;否则不加上参数就不会显示调试信息。

    参看:C语言再学习 -- C 预处理器


    2、使用 gcc 和 gdb

    1)调试步骤

    A、为了能够使用 gdb 调试程序,在编译阶段加上 -g 参数。

    [cpp] view plain copy
    1. root@# gcc -g test.c  
    B、使用 gdb 命令调试程序

    [cpp] view plain copy
    1. root@# gdb a.out   
    2. GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02  
    3. Copyright (C) 2012 Free Software Foundation, Inc.  
    4. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>  
    5. This is free software: you are free to change and redistribute it.  
    6. There is NO WARRANTY, to the extent permitted by law.  Type "show copying"  
    7. and "show warranty" for details.  
    8. This GDB was configured as "i686-linux-gnu".  
    9. For bug reporting instructions, please see:  
    10. <http://bugs.launchpad.net/gdb-linaro/>...  
    11. Reading symbols from /home/tarena/project/c_test/a.out...done.  
    12. (gdb)   
    C、进入 gdb 后,运行程序

    [cpp] view plain copy
    1. (gdb) r  
    2. Starting program: /home/tarena/project/c_test/a.out   
    3.   
    4. Program received signal SIGSEGV, Segmentation fault.  
    5. 0x080483c4 in main () at test.c:6  
    6. 6       *ptr = 10;  
    7. (gdb)   

    从输出看出,程序收到 SIGSEGV 信号,触发段错误,并提示地址 0x080483c4、创建了一个空指针,然后试图访问它的值(读值)。

    可以通过man 7 signal查看SIGSEGV的信息

    [cpp] view plain copy
    1. Signal     Value     Action   Comment  
    2.       ──────────────────────────────────────────────────────────────────────  
    3.       SIGHUP        1       Term    Hangup detected on controlling terminal  
    4.                                     or death of controlling process  
    5.       SIGINT        2       Term    Interrupt from keyboard  
    6.       SIGQUIT       3       Core    Quit from keyboard  
    7.       SIGILL        4       Core    Illegal Instruction  
    8.       SIGABRT       6       Core    Abort signal from abort(3)  
    9.       SIGFPE        8       Core    Floating point exception  
    10.       SIGKILL       9       Term    Kill signal  
    11.       SIGSEGV      11       Core    Invalid memory reference  
    12.       SIGPIPE      13       Term    Broken pipe: write to pipe with no  
    13.                                     readers  
    14.       SIGALRM      14       Term    Timer signal from alarm(2)  
    15.       SIGTERM      15       Term    Termination signal  
    16.       SIGUSR1   30,10,16    Term    User-defined signal 1  
    17.       SIGUSR2   31,12,17    Term    User-defined signal 2  
    18.       SIGCHLD   20,17,18    Ign     Child stopped or terminated  
    19.       SIGCONT   19,18,25    Cont    Continue if stopped  
    20.       SIGSTOP   17,19,23    Stop    Stop process  
    21.       SIGTSTP   18,20,24    Stop    Stop typed at tty  
    22.       SIGTTIN   21,21,26    Stop    tty input for background process  
    23.       SIGTTOU   22,22,27    Stop    tty output for background process  
    24.   
    25.       The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.  

    D、完成调试后,输入 q 命令退出 gdb

    [cpp] view plain copy
    1. (gdb) q  
    2. A debugging session is active.  
    3.   
    4.     Inferior 1 [process 3483] will be killed.  
    5.   
    6. Quit anyway? (y or n) y  


    2)适用场景

    A、仅当能确定程序一定会发生段错误的情况下适用。

    B、当程序的源码可以获得的情况下,使用 -g 参数编译程序

    C、一般用于测试阶段,生产环境下 gdb 会有副作用:使程序运行减慢,运行不够稳定,等等。

    D、即使在测试阶段,如果程序过于复杂,gdb 也不能处理。


    3、使用 core 文件和 gdb

    上面有提到段错误触发SIGSEGV信号,通过man 7 signal,可以看到SIGSEGV默认的处理程序(handler)会打印段错误信息,并产生 core 文件,由此我们可以借助于程序异常退出生成的 core 文件中的调试信息,使用 gdb 工具来调试程序中的段错误。

    1)调试步骤

    A、在一些Linux版本下,默认是不产生 core 文件的,首先可以查看一下系统 core 文件的大小限制:

    [cpp] view plain copy
    1. root@# ulimit -c  
    2. 0  
    B、可以看到默认设置情况下,本机Linux环境下发生段错误不会自动生成 core 文件,下面设置下 core 文件的大小限制(单位为KB)
    [cpp] view plain copy
    1. root@# ulimit -c 1024  
    2. root@# ulimit -c   
    3. 1024  
    C、运行程序,发生段错误生成的 core 文件

    [cpp] view plain copy
    1. root@# ./a.out   
    2. 段错误 (核心已转储)  
    D、加载 core 文件,使用 gdb 工具进行调试

    [cpp] view plain copy
    1. root@ubuntu:/home/tarena/project/c_test# gdb a.out core   
    2. GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02  
    3. Copyright (C) 2012 Free Software Foundation, Inc.  
    4. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>  
    5. This is free software: you are free to change and redistribute it.  
    6. There is NO WARRANTY, to the extent permitted by law.  Type "show copying"  
    7. and "show warranty" for details.  
    8. This GDB was configured as "i686-linux-gnu".  
    9. For bug reporting instructions, please see:  
    10. <http://bugs.launchpad.net/gdb-linaro/>...  
    11. Reading symbols from /home/tarena/project/c_test/a.out...done.  
    12. [New LWP 3491]  
    13.   
    14. warning: Can't read pathname for load map: 输入/输出错误.  
    15. Core was generated by `./a.out'.  
    16. Program terminated with signal 11, Segmentation fault.  
    17. #0  0x080483c4 in main () at test.c:6  
    18. 6       *ptr = 10;  
    19. (gdb)   
    从输出看出,可以显示出异样的段错误信息

    E、完成调试后,输入 q 命令退出 gdb

    [cpp] view plain copy
    1. (gdb) q  
    2)适用场景

    A、适合于在实际生成环境下调试程度的段错误(即在不用重新发生段错误的情况下重现段错误)

    B、当程序很复杂,core 文件相当大时,该方法不可用


    4、使用 objdump

    1)调试步骤

    A、使用 dmesg 命令,找到最近发生的段错误输入信息

    [cpp] view plain copy
    1. root@# dmesg  
    2. [  372.350652] a.out[2712]: segfault at 0 ip 080483c4 sp bfd1f7b8 error 6 in a.out[8048000+1000]  

    其中,对我们接下来的调试过程有用的是发生段错误的地址 0 和指令指针地址 080483c4。

    有时候,“地址引起的错”可以告诉你问题的根源。看到上面的例子,我们可以说,int *ptr = NULL; *ptr = 10;,创建了一个空指针,然后试图访问它的值(读值)。

    B、使用 objdump 生成二进制的相关信息,重定向到文件中

    [cpp] view plain copy
    1. root@# objdump -d a.out > a.outDump   
    2. root@# ls  
    3. a.out  a.outDump  core  test.c    
    其中,生成的 a.outDump 文件中包含了二进制文件的 a.out 的汇编代码

    C、在 a.outDump 文件中查找发生段错误的地址

    [cpp] view plain copy
    1. root@ubuntu:/home/tarena/project/c_test# grep -n -A 10 -B 10 "0" a.outDump  
    2. 1-  
    3. 2-a.out:     file format elf32-i386  
    4.   
    5. 118:080483b4 <main>:  
    6. 119: 80483b4:   55                      push   %ebp  
    7. 120: 80483b5:   89 e5                   mov    %esp,%ebp  
    8. 121: 80483b7:   83 ec 10                sub    $0x10,%esp  
    9. 122: 80483ba:   c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)  
    10. 123: 80483c1:   8b 45 fc                mov    -0x4(%ebp),%eax  
    11. 124: 80483c4:   c7 00 0a 00 00 00       movl   $0xa,(%eax)  
    12. 125: 80483ca:   b8 00 00 00 00          mov    $0x0,%eax  
    13. 126: 80483cf:   c9                      leave    
    14. 127: 80483d0:   c3                      ret      
    15. 128: 80483d1:   90                      nop  
    16. 129: 80483d2:   90                      nop  
    17. 130: 80483d3:   90                      nop  
    18. 131: 80483d4:   90                      nop  
    19. 132: 80483d5:   90                      nop  
    20. 133: 80483d6:   90                      nop  
    21. 134: 80483d7:   90                      nop  
    22. 135: 80483d8:   90                      nop  
    23. 136: 80483d9:   90                      nop  
    24. 137: 80483da:   90                      nop  
    25. 138: 80483db:   90                      nop  
    26. 139: 80483dc:   90                      nop  
    27. 140: 80483dd:   90                      nop  
    28. 141: 80483de:   90                      nop  
    29. 142: 80483df:   90                      nop  
    通过对以上汇编代码分析,得知段错误发生main函数,对应的汇编指令是movl   $0xa,(%eax),接下来打开程序的源码,找到汇编指令对应的源码,也就定位到段错误了。 

    2)适用场景

    A、不需要 -g 参数编译,不需要借助于core文件,但需要有一定的汇编语言基础。

    B、如果使用 gcc 编译优化参数(-O1,-O2,-O3)的话,生成的汇编指令将会被优化,使得调试过程有些难度。


    5、使用catchsegv

    catchsegv 命令专门用来补货段错误,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的 库(/lib/libSegFault.so)加载上,用于捕捉段错误的出错信息。

    [cpp] view plain copy
    1. root@t# catchsegv ./a.out  
    2. Segmentation fault (core dumped)  
    3. *** Segmentation fault  
    4. Register dump:  
    5.   
    6.  EAX: 00000000   EBX: b77a1ff4   ECX: bfd8a0e4   EDX: bfd8a074  
    7.  ESI: 00000000   EDI: 00000000   EBP: bfd8a048   ESP: bfd8a038  
    8.   
    9.  EIP: 080483c4   EFLAGS: 00010282  
    10.   
    11.  CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b  
    12.   
    13.  Trap: 0000000e   Error: 00000006   OldMask: 00000000  
    14.  ESP/signal: bfd8a038   CR2: 00000000  
    15.   
    16. Backtrace:  
    17. ??:0(main)[0x80483c4]  
    18. /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb761a4d3]  
    19. ??:0(_start)[0x8048321]  
    20.   
    21. Memory map:  
    22.   
    23. 08048000-08049000 r-xp 00000000 08:01 2102158 /home/tarena/project/c_test/a.out  
    24. 08049000-0804a000 r--p 00000000 08:01 2102158 /home/tarena/project/c_test/a.out  
    25. 0804a000-0804b000 rw-p 00001000 08:01 2102158 /home/tarena/project/c_test/a.out  
    26. 09467000-0948c000 rw-p 00000000 00:00 0 [heap]  
    27. b75e1000-b75fd000 r-xp 00000000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1  
    28. b75fd000-b75fe000 r--p 0001b000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1  
    29. b75fe000-b75ff000 rw-p 0001c000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1  
    30. b75ff000-b7601000 rw-p 00000000 00:00 0  
    31. b7601000-b77a0000 r-xp 00000000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so  
    32. b77a0000-b77a2000 r--p 0019f000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so  
    33. b77a2000-b77a3000 rw-p 001a1000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so  
    34. b77a3000-b77a6000 rw-p 00000000 00:00 0  
    35. b77b8000-b77bb000 r-xp 00000000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so  
    36. b77bb000-b77bc000 r--p 00002000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so  
    37. b77bc000-b77bd000 rw-p 00003000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so  
    38. b77bd000-b77bf000 rw-p 00000000 00:00 0  
    39. b77bf000-b77c0000 r-xp 00000000 00:00 0 [vdso]  
    40. b77c0000-b77e0000 r-xp 00000000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so  
    41. b77e0000-b77e1000 r--p 0001f000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so  
    42. b77e1000-b77e2000 rw-p 00020000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so  
    43. bfd6b000-bfd8c000 rw-p 00000000 00:00 0 [stack]  


    五、一些注意事项

    1)出现段错误时,首先应该想到段错误的定义,从它出发考虑引发错误的原因。

    2)在使用指针时,定义了指针后记得初始化指针,在使用的时候记得判断是否为 NULL

    3)在使用数组时,注意数组是否被初始化,数组下标是否越界,数组元素是否存在等

    4)在访问变量,注意变量所占地址空间是否已经被程序释放掉

    5)在处理变量时,注意变量的格式控制是否合理等


    展开全文
  • 段错误原因分析和查找

    万次阅读 2014-07-10 15:02:58
    一、 段错误原因分析  1 使用非法的指针,包括使用未经初始化及已经释放的指针(指针使用之前和释放之后置为NULL)  2 内存读/写越界。包括数组访问越界,或在使用一些写内存的函数时,长度指定不正确或者...

    http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html

    最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fault)。借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决。

    1. 段错误是什么

    一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义(参考Answers.com):

    复制代码
    A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.
    
    Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.
    
    On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.
    复制代码

    2. 段错误产生的原因

    2.1 访问不存在的内存地址

    复制代码
    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            int *ptr = NULL;
            *ptr = 0;
    }
    复制代码

    2.2 访问系统保护的内存地址

    复制代码
    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            int *ptr = (int *)0;
            *ptr = 100;
    }
    复制代码

    2.3 访问只读的内存地址

    复制代码
    #include<stdio.h>
    #include<stdlib.h>
    #include<string.h>
    void main()
    {
            char *ptr = "test";
            strcpy(ptr, "TEST");
    }
    复制代码

    2.4 栈溢出

    复制代码
    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            main();
    }
    复制代码

    等等其他原因。

    3. 段错误信息的获取

    程序发生段错误时,提示信息很少,下面有几种查看段错误的发生信息的途径。

    3.1 dmesg

    dmesg可以在应用程序crash掉时,显示内核中保存的相关信息。如下所示,通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ dmesg
    [ 2329.479037] segfault3[2700]: segfault at 80484e0 ip 00d2906a sp bfbbec3c error 7 in libc-2.10.1.so[cb4000+13e000]

    3.2 -g

    使用gcc编译程序的源码时,加上-g参数,这样可以使得生成的二进制文件中加入可以用于gdb调试的有用信息。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

    3.3 nm

    使用nm命令列出二进制文件中的符号表,包括符号地址、符号类型、符号名等,这样可以帮助定位在哪里发生了段错误。以程序2.3为例:

    复制代码
    panfeng@ubuntu:~/segfault$ nm segfault3
    08049f20 d _DYNAMIC
    08049ff4 d _GLOBAL_OFFSET_TABLE_
    080484dc R _IO_stdin_used
             w _Jv_RegisterClasses
    08049f10 d __CTOR_END__
    08049f0c d __CTOR_LIST__
    08049f18 D __DTOR_END__
    08049f14 d __DTOR_LIST__
    080484ec r __FRAME_END__
    08049f1c d __JCR_END__
    08049f1c d __JCR_LIST__
    0804a014 A __bss_start
    0804a00c D __data_start
    08048490 t __do_global_ctors_aux
    08048360 t __do_global_dtors_aux
    0804a010 D __dso_handle
             w __gmon_start__
    0804848a T __i686.get_pc_thunk.bx
    08049f0c d __init_array_end
    08049f0c d __init_array_start
    08048420 T __libc_csu_fini
    08048430 T __libc_csu_init
             U __libc_start_main@@GLIBC_2.0
    0804a014 A _edata
    0804a01c A _end
    080484bc T _fini
    080484d8 R _fp_hw
    080482bc T _init
    08048330 T _start
    0804a014 b completed.6990
    0804a00c W data_start
    0804a018 b dtor_idx.6992
    080483c0 t frame_dummy
    080483e4 T main
             U memcpy@@GLIBC_2.0
    复制代码

    3.4 ldd

    使用ldd命令查看二进制程序的共享链接库依赖,包括库的名称、起始地址,这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ ldd ./segfault3
        linux-gate.so.1 =>  (0x00e08000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00675000)
        /lib/ld-linux.so.2 (0x00482000)

    4. 段错误的调试方法

    4.1 使用printf输出信息

    这个是看似最简单但往往很多情况下十分有效的调试方式,也许可以说是程序员用的最多的调试方式。简单来说,就是在程序的重要代码附近加上像printf这类输出信息,这样可以跟踪并打印出段错误在代码中可能出现的位置。

    为了方便使用这种方法,可以使用条件编译指令#ifdef DEBUG和#endif把printf函数包起来。这样在程序编译时,如果加上-DDEBUG参数就能查看调试信息;否则不加该参数就不会显示调试信息。

    4.2 使用gcc和gdb

    4.2.1 调试步骤

     1、为了能够使用gdb调试程序,在编译阶段加上-g参数,以程序2.3为例:

    panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

    2、使用gdb命令调试程序:

    复制代码
    panfeng@ubuntu:~/segfault$ gdb ./segfault3 
    GNU gdb (GDB) 7.0-ubuntu
    Copyright (C) 2009 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 "i486-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /home/panfeng/segfault/segfault3...done.
    (gdb) 
    复制代码

    3、进入gdb后,运行程序:

    复制代码
    (gdb) run
    Starting program: /home/panfeng/segfault/segfault3 
    
    Program received signal SIGSEGV, Segmentation fault.
    0x001a306a in memcpy () from /lib/tls/i686/cmov/libc.so.6
    (gdb) 
    复制代码

    从输出看出,程序2.3收到SIGSEGV信号,触发段错误,并提示地址0x001a306a、调用memcpy报的错,位于/lib/tls/i686/cmov/libc.so.6库中。

    4、完成调试后,输入quit命令退出gdb:

    复制代码
    (gdb) quit
    A debugging session is active.
    
        Inferior 1 [process 3207] will be killed.
    
    Quit anyway? (y or n) y
    复制代码

    4.2.2 适用场景

    1、仅当能确定程序一定会发生段错误的情况下使用。

    2、当程序的源码可以获得的情况下,使用-g参数编译程序。

    3、一般用于测试阶段,生产环境下gdb会有副作用:使程序运行减慢,运行不够稳定,等等。

    4、即使在测试阶段,如果程序过于复杂,gdb也不能处理。

    4.3 使用core文件和gdb

    在4.2节中提到段错误会触发SIGSEGV信号,通过man 7 signal,可以看到SIGSEGV默认的handler会打印段错误出错信息,并产生core文件,由此我们可以借助于程序异常退出时生成的core文件中的调试信息,使用gdb工具来调试程序中的段错误。

    4.3.1 调试步骤

    1、在一些Linux版本下,默认是不产生core文件的,首先可以查看一下系统core文件的大小限制:

    panfeng@ubuntu:~/segfault$ ulimit -c
    0

    2、可以看到默认设置情况下,本机Linux环境下发生段错误时不会自动生成core文件,下面设置下core文件的大小限制(单位为KB):

    panfeng@ubuntu:~/segfault$ ulimit -c 1024
    panfeng@ubuntu:~/segfault$ ulimit -c
    1024

    3、运行程序2.3,发生段错误生成core文件:

    panfeng@ubuntu:~/segfault$ ./segfault3
    段错误 (core dumped)

    4、加载core文件,使用gdb工具进行调试:

    复制代码
    panfeng@ubuntu:~/segfault$ gdb ./segfault3 ./core 
    GNU gdb (GDB) 7.0-ubuntu
    Copyright (C) 2009 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 "i486-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /home/panfeng/segfault/segfault3...done.
    
    warning: Can't read pathname for load map: 输入/输出错误.
    Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
    Loaded symbols for /lib/tls/i686/cmov/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
    Loaded symbols for /lib/ld-linux.so.2
    Core was generated by `./segfault3'.
    Program terminated with signal 11, Segmentation fault.
    #0  0x0018506a in memcpy () from /lib/tls/i686/cmov/libc.6
    复制代码

    从输出看出,同4.2.1中一样的段错误信息。

    5、完成调试后,输入quit命令退出gdb:

    (gdb) quit

    4.3.2 适用场景

    1、适合于在实际生成环境下调试程序的段错误(即在不用重新发生段错误的情况下重现段错误)。

    2、当程序很复杂,core文件相当大时,该方法不可用。

    4.4 使用objdump

    4.4.1 调试步骤

    1、使用dmesg命令,找到最近发生的段错误输出信息:

    panfeng@ubuntu:~/segfault$ dmesg
    ... ...
    [17257.502808] segfault3[3320]: segfault at 80484e0 ip 0018506a sp bfc1cd6c error 7 in libc-2.10.1.so[110000+13e000]

    其中,对我们接下来的调试过程有用的是发生段错误的地址:80484e0和指令指针地址:0018506a。

    2、使用objdump生成二进制的相关信息,重定向到文件中:

    panfeng@ubuntu:~/segfault$ objdump -d ./segfault3 > segfault3Dump

    其中,生成的segfault3Dump文件中包含了二进制文件的segfault3的汇编代码。

    3、在segfault3Dump文件中查找发生段错误的地址:

    复制代码
    panfeng@ubuntu:~/segfault$ grep -n -A 10 -B 10 "80484e0" ./segfault3Dump 
    121- 80483df:    ff d0                    call   *%eax
    122- 80483e1:    c9                       leave  
    123- 80483e2:    c3                       ret    
    124- 80483e3:    90                       nop
    125-
    126-080483e4 <main>:
    127- 80483e4:    55                       push   %ebp
    128- 80483e5:    89 e5                    mov    %esp,%ebp
    129- 80483e7:    83 e4 f0                 and    $0xfffffff0,%esp
    130- 80483ea:    83 ec 20                 sub    $0x20,%esp
    131: 80483ed:    c7 44 24 1c e0 84 04     movl   $0x80484e0,0x1c(%esp)
    132- 80483f4:    08 
    133- 80483f5:    b8 e5 84 04 08           mov    $0x80484e5,%eax
    134- 80483fa:    c7 44 24 08 05 00 00     movl   $0x5,0x8(%esp)
    135- 8048401:    00 
    136- 8048402:    89 44 24 04              mov    %eax,0x4(%esp)
    137- 8048406:    8b 44 24 1c              mov    0x1c(%esp),%eax
    138- 804840a:    89 04 24                 mov    %eax,(%esp)
    139- 804840d:    e8 0a ff ff ff           call   804831c <memcpy@plt>
    140- 8048412:    c9                       leave  
    141- 8048413:    c3                       ret    
    复制代码

    通过对以上汇编代码分析,得知段错误发生main函数,对应的汇编指令是movl $0x80484e0,0x1c(%esp),接下来打开程序的源码,找到汇编指令对应的源码,也就定位到段错误了。

    4.4.2 适用场景

    1、不需要-g参数编译,不需要借助于core文件,但需要有一定的汇编语言基础。

    2、如果使用了gcc编译优化参数(-O1,-O2,-O3)的话,生成的汇编指令将会被优化,使得调试过程有些难度。

    4.5 使用catchsegv

    catchsegv命令专门用来扑获段错误,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的库(/lib/libSegFault.so)加载上,用于捕捉断错误的出错信息。

    复制代码
    panfeng@ubuntu:~/segfault$ catchsegv ./segfault3
    Segmentation fault (core dumped)
    *** Segmentation fault
    Register dump:
    
     EAX: 00000000   EBX: 00fb3ff4   ECX: 00000002   EDX: 00000000
     ESI: 080484e5   EDI: 080484e0   EBP: bfb7ad38   ESP: bfb7ad0c
    
     EIP: 00ee806a   EFLAGS: 00010203
    
     CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b
    
     Trap: 0000000e   Error: 00000007   OldMask: 00000000
     ESP/signal: bfb7ad0c   CR2: 080484e0
    
    Backtrace:
    /lib/libSegFault.so[0x3b606f]
    ??:0(??)[0xc76400]
    /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xe89b56]
    /build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8048351]
    
    Memory map:
    
    00258000-00273000 r-xp 00000000 08:01 157 /lib/ld-2.10.1.so
    00273000-00274000 r--p 0001a000 08:01 157 /lib/ld-2.10.1.so
    00274000-00275000 rw-p 0001b000 08:01 157 /lib/ld-2.10.1.so
    003b4000-003b7000 r-xp 00000000 08:01 13105 /lib/libSegFault.so
    003b7000-003b8000 r--p 00002000 08:01 13105 /lib/libSegFault.so
    003b8000-003b9000 rw-p 00003000 08:01 13105 /lib/libSegFault.so
    00c76000-00c77000 r-xp 00000000 00:00 0 [vdso]
    00e0d000-00e29000 r-xp 00000000 08:01 4817 /lib/libgcc_s.so.1
    00e29000-00e2a000 r--p 0001b000 08:01 4817 /lib/libgcc_s.so.1
    00e2a000-00e2b000 rw-p 0001c000 08:01 4817 /lib/libgcc_s.so.1
    00e73000-00fb1000 r-xp 00000000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb1000-00fb2000 ---p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb2000-00fb4000 r--p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb4000-00fb5000 rw-p 00140000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb5000-00fb8000 rw-p 00000000 00:00 0
    08048000-08049000 r-xp 00000000 08:01 303895 /home/panfeng/segfault/segfault3
    08049000-0804a000 r--p 00000000 08:01 303895 /home/panfeng/segfault/segfault3
    0804a000-0804b000 rw-p 00001000 08:01 303895 /home/panfeng/segfault/segfault3
    09432000-09457000 rw-p 00000000 00:00 0 [heap]
    b78cf000-b78d1000 rw-p 00000000 00:00 0
    b78df000-b78e1000 rw-p 00000000 00:00 0
    bfb67000-bfb7c000 rw-p 00000000 00:00 0 [stack]
    复制代码

    5. 一些注意事项

    1、出现段错误时,首先应该想到段错误的定义,从它出发考虑引发错误的原因。

    2、在使用指针时,定义了指针后记得初始化指针,在使用的时候记得判断是否为NULL。

    3、在使用数组时,注意数组是否被初始化,数组下标是否越界,数组元素是否存在等。

    4、在访问变量时,注意变量所占地址空间是否已经被程序释放掉。

    5、在处理变量时,注意变量的格式控制是否合理等。

    6. 参考资料列表

    1、http://www.docin.com/p-105923877.html

    2、http://blog.chinaunix.net/space.php?uid=317451&do=blog&id=92412



    http://qgjie456.blog.163.com/blog/static/35451367201112722827742/

    一、 段错误原因分析


             1 使用非法的指针,包括使用未经初始化及已经释放的指针(指针使用之前和释放之后置为NULL)

             2 内存读/写越界。包括数组访问越界,或在使用一些写内存的函数时,长度指定不正确或者这些函数本身不能指定长度,典型的函数有strcpy(strncpy),sprintf

    (snprint)等等。

             3 对于C++对象,请通过相应类的接口来去内存进行操作,禁止通过其返回的指针对内存进行写操作,典型的如string类的data()和c_str()两个接口。

             4 函数不要返回其中局部对象的引用或地址,当函数返回时,函数栈弹出,局部对象的地址将失效,改写或读这些地址都会造成未知的后果。

             5 避免在栈中定义过大的数组,否则可能导致进程的栈空间不足,此时也会出现段错误。

             6 操作系统的相关限制,如:进程可以分配的最大内存,进程可以打开的最大文件描述符个数等,这些需要通过ulimit或setrlimit或sysctl来解除相关的限制。

             7 多线程的程序,涉及到多个线程同时操作一块内存时必须进行互斥,否则内存中的内存将不可预料

             8 使用非线程安全的函数调用,例如 strerror 函数等

             9 在有信号的环境中,使用不可重入函数调用,而这些函数内部会读或写某片内存区,当信号中断时,内存写操作将被打断,而下次进入时将不避免的出错。

             10 跨进程传递某个地址

            11 某些有特殊要求的系统调用,例如epool_wait,正常情况下使用close关闭一个套接字后,epool会不再返回这个socket上的事件,但是如果你使用dup或dup2操作,将

    导致epool无法进行移除操作。


    二、 段错误原因查找

    1) 查看函数调用栈

        在头文件"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);
         }
         free (strings);
    }

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

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

    备注:void *const *buffer -- buffer指向char类型的常量指针的指针(很是拗口)

    2) 查看寄存器内容
    要查看寄存器内容有两个解决办法:

    A) 在内核里面把这些寄存器打印出来;

          

        段错误原因分析和查找 - ququ - linux 学习

           一:段错误时内核执行路径

    根据上图,我们只需要在__do_user_fault的时候把打印信息打开就可以了,如下:

    #ifdef CONFIG_DEBUG_USER

           if (user_debug & UDBG_SEGV) {

                  printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                         tsk->comm, sig, addr, fsr);

                  show_pte(tsk->mm, addr);

                  show_regs(regs);

           }

    #endif

    改成

    printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                         tsk->comm, sig, addr, fsr);

                  show_pte(tsk->mm, addr);

                  show_regs(regs);

    就可以了;

          里面会打印出pc寄存器的值。

    B) 在上层程序里面把寄存器打印出来;


    这个做法的主要思路就是先拦截SIGSEGV信号,然后在信号处理函数里面打印信息:

    信号拦截代码如下:

    static void  catch_sigsegv()

    {

           struct sigaction action;

           memset(&action, 0, sizeof(action));

           action.sa_sigaction = sigsegv_handler;

           action.sa_flags = SA_SIGINFO;       // 注意这里,flag 是 SA_SIGINFO,这样信号处理函数就会多一些信息。

           if(sigaction(SIGSEGV, &action, NULL) < 0){

                  perror("sigaction");

    }

    }

    只需要在main函数里面加入这个函数就可以了,

    main(…)

    {

    ….

    catch_sigsegv();

    }

     

    下面来看看这个处理函数sigsegv_handler是怎么写的,代码如下:

    #include <memory.h>

    #include <stdlib.h>

    #include <stdio.h>

    #include <unistd.h>

    #include <signal.h>

    #include <ucontext.h>

    #include <dlfcn.h>

    static void sigsegv_handler(int signum, siginfo_t* info, void*ptr)

    {

            static const char *si_codes[3] = {"", "SEGV_MAPERR", "SEGV_ACCERR"};

            int i;

            ucontext_t *ucontext = (ucontext_t*)ptr;

            void *bt[100];

            char **strings;


            printf("Segmentation Fault Trace:\n");

            printf("info.si_signo = %d\n", signum);

            printf("info.si_errno = %d\n", info->si_errno);

            printf("info.si_code  = %d (%s)\n", info->si_code, si_codes[info->si_code]);

            printf("info.si_addr  = %p\n", info->si_addr);

     

            /*for arm*/

            printf("the arm_fp 0x%3x\n",ucontext->uc_mcontext.arm_fp);

            printf("the arm_ip 0x%3x\n",ucontext->uc_mcontext.arm_ip);

            printf("the arm_sp 0x%3x\n",ucontext->uc_mcontext.arm_sp);

            printf("the arm_lr 0x%3x\n",ucontext->uc_mcontext.arm_lr);

            printf("the arm_pc 0x%3x\n",ucontext->uc_mcontext.arm_pc);

            printf("the arm_cpsr 0x%3x\n",ucontext->uc_mcontext.arm_cpsr);

            printf("the falut_address 0x%3x\n",ucontext->uc_mcontext.fault_address);

     

            printf("Stack trace (non-dedicated):");

            int sz = backtrace(bt, 20);

            printf("the stack trace is %d\n",sz);

            strings = backtrace_symbols(bt, sz);

            for(i = 0; i < sz; ++i){

                    printf("%s\n", strings[i]);

            }

        _exit (-1);

    }

     

     

    测试代码如下:

    void test_segv()

    {

            char *i=0;

            *i=10;

    }

     

    void cause_segv()

    {

            printf("this is the cause_segv\n");

            test_segv();

    }

    int main(int argc,char **argv)

    {

            catch_sigsegv();

            cause_segv();

            return 0;

    }

    编译方法:

    gcc segment_trace.c -g –rdynamic –o segment_trace

    执行:

    ./segment_trace

    输出如下:

    this is the catch_sigsegv

    Segmentation Fault Trace:

    info.si_signo = 11

    info.si_errno = 0

    info.si_code  = 1 (SEGV_MAPERR)

    info.si_addr  = (nil)

    the arm_fp 0xb7f8a3d4

    the arm_ip 0xb7f8a3d8

    the arm_sp 0xb7f8a3c0

    the arm_lr 0x8998

    the arm_pc 0x8974

    the arm_cpsr 0x60000010

    the falut_address 0x  0

    Stack trace (non-dedicated):the stack trace is 5

    ./segment_trace(backtrace_symbols+0x1c8) [0x8844]

    /lib/libc.so.6(__default_rt_sa_restorer+0) [0xb5e22230]

    ./segment_trace(cause_segv+0x18) [0x8998]

    ./segment_trace(main+0x20) [0x89c0]

    /lib/libc.so.6(__libc_start_main+0x108) [0xb5e0c10c]


        C) 输出信息分析 

    根据上面的输出可以看出一些端倪:

    根据栈信息,可以看出是在cause_segv里面出了问题,但是最后一层栈信息是看不到的,另外需要根据pc寄存器的值来定位:

    addr2line  -f -e segment_trace 0x8974

    test_segv

    /home/wf/test/segment_trace.c:55

    可以看到说是在55行,一看:

    刚好是

    *i=10;

    这一行,

    而且可以看出,函数名是test_segv

    所以基本上不需要打印栈信息,也可以定位了。

    也可以使用 objdump 工具:

    objdump -S -l -z  -j .text segment_trace   >1.txt

    查看 0x8974 地址的代码。



    http://baike.baidu.com/link?url=-xg1OCMI1mu87OU0zuI4yxKur5TN4J6Rt4-ApMqawO7cWUobl62xYS3EfcxqE9REbGIMic3mynwSq4-4qp4y_K

    百度百科上关于段错误的资料。


    http://wenku.baidu.com/link?url=waqeLu5VaUVyO0GuogoykFwv2EACmiQBBHElpce56DoXtlwIGfPsQFmOjI7s-GFlSx8mJaviBwUSaTsM7etQ77ykcCeNP2KOnpe6HCRTtqW

    A

    segmentation

    fault

    (often

    shortened

    to

    SIGSEGV

    )

    is

    a

    particular

    error

    condition

    that

    can

    occur

    during

    the

    operation

    of

    computer

    software

    .

    A

    segmentation

    fault

    occurs

    when

    a

    program

    attempts

    to

    access

    a

    memory

    location

    that

    it

    is

    not

    allowed

    to

    access,

    or

    attempts

    to

    access

    a

    memory

    location

    in

    a

    way

    that

    is

    not

    allowed

    (for

    example,

    attempting

    to

    write

    to

    a

    read-only

    location,

    or

    to

    overwrite

    part

    of

    the

    operating

    system).

    Segmentation

    is

    one

    approach

    to

    memory

    management

    and

    protection

    in

    the

    operating

    system

    .

    It

    has

    been

    superseded

    by

    paging

    for

    most

    purposes,

    but

    much

    of

    the

    terminology

    of

    segmentation

    is

    still

    used,

    "segmentation

    fault"

    being

    an

    example.

    Some

    operating

    systems

    still

    have

    segmentation

    at

    some

    logical

    level

    although

    paging

    is

    used

    as

    the

    main

    memory

    management

    policy.

    On

    Unix-like

    operating

    systems,

    a

    process

    that

    accesses

    an

    invalid

    memory

    address

    receives

    the

    SIGSEGV

    signal

    .

    On

    Microsoft

    Windows

    ,

    a

    process

    that

    accesses

    invalid

    memory

    receives

    the

    STATUS_ACCESS_VIOLATION

    exception

    .

    上述文字没有给出

    SIGSEGV

    的定义,仅仅说它是“计算机软件操作过程中的一种错误

    情况”。文字描述了

    SIGSEGV

    在何时发生,即“当程序试图访问不被允许访问的内存区域

    (比如,尝试写一块属于操作系统的内存)

    ,或以错误的类型访问内存区域(比如,尝试写

    一块只读内存)

    这个描述是准确的。

    为了加深理解,

    我们再更加详细的概括一下

    SIGSEGV

    SIGSEGV

    是在访问内存时发生的错误,它属于内存管理的范畴

    SIGSEGV

    是一个用户态的概念,是操作系统在用户态程序错误访问内存时所做出的处

    理。

    当用户态程序访问(访问表示读、写或执行)不允许访问的内存时,产生

    SIGSEGV

    当用户态程序以错误的方式访问允许访问的内存时,产生

    SIGSEGV

    从用户态程序开发的角度,

    我们并不需要理解操作系统复杂的内存管理机制,

    这是和硬

    件平台相关的。但是,了解内核发送

    SIGSEGV

    信号的流程,对我们理解

    SIGSEGV

    是很有

    Understanding

    Linux

    Kernel

    Edition

    3

    和《

    Understanding

    the

    Linux

    Virtual

    Memory

    Manager

    》相关章节都有一幅总图对此描述,对比之下,笔者认为

    ULK

    的图更为直观。

    Segmentation

    Fault

    in

    Linux

    6

    Y

    e

    s

    N

    o

    访

    (读、写、执

    是否符合该内存区域类型

    (指

    page fault

    Y

    e

    s

    N

    o

    访

    ,分

    访

    ,发

    segfault

    Y

    e

    s

    N

    o

    Page fault

    1.

    SIGSEGV

    Overview

    1

    红色部分展示了内核发送

    SIGSEGV

    信号给用户态程序的总体流程。当用户态

    程序访问一个会引发

    SIGSEGV

    的地址时,硬件首先产生一个

    page

    fault

    ,即“缺页异常”。

    在内核的

    page

    fault

    处理函数中,

    首先判断该地址是否属于用户态程序的地址空间

    [*]

    Intel

    32bit

    IA32

    架构的

    CPU

    为例,

    用户态程序的地址空间为

    [0

    3G]

    内核地址空间为

    [3G

    4G]

    如果该地址属于用户态地址空间,

    检查访问的类型是否和该内存区域的类型是否匹配,

    不匹

    配,则发送

    SIGSEGV

    信号;如果该地址不属于用户态地址空间,检查访问该地址的操作是

    否发生在用户态,如果是,发送

    SIGSEGV

    信号。

    [*]

    这里的用户态程序地址空间,特指程序可以访问的地址空间范围。如果广义的说,

    一个进程的地址空间应该包括内核空间部分,只是它不能访问而已。

    2

    更为详细的描绘了内核发送

    SIGSEGV

    信号的流程。在这里我们不再累述图中

    流程,在后面章节的例子中,笔者会结合实际,描述具体的流程






    展开全文
  • Linux环境下段错误的产生原因及调试方法小结

    万次阅读 多人点赞 2018-07-06 11:12:26
    http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且...借此机会系统学习了一下,这里对Linux环境下的段错误做个小...

    http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html

    最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fault)。借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决。

    1. 段错误是什么

    一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义(参考Answers.com):

    A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.
    
    Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.
    
    On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.

    2. 段错误产生的原因

    2.1 访问不存在的内存地址

    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            int *ptr = NULL;
            *ptr = 0;
    }

    2.2 访问系统保护的内存地址

    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            int *ptr = (int *)0;
            *ptr = 100;
    }

    2.3 访问只读的内存地址

    #include<stdio.h>
    #include<stdlib.h>
    #include<string.h>
    void main()
    {
            char *ptr = "test";
            strcpy(ptr, "TEST");
    }

    2.4 栈溢出

    #include<stdio.h>
    #include<stdlib.h>
    void main()
    {
            main();
    }

    等等其他原因。

    3. 段错误信息的获取

    程序发生段错误时,提示信息很少,下面有几种查看段错误的发生信息的途径。

    3.1 dmesg

    dmesg可以在应用程序crash掉时,显示内核中保存的相关信息。如下所示,通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ dmesg
    [ 2329.479037] segfault3[2700]: segfault at 80484e0 ip 00d2906a sp bfbbec3c error 7 in libc-2.10.1.so[cb4000+13e000]

    3.2 -g

    使用gcc编译程序的源码时,加上-g参数,这样可以使得生成的二进制文件中加入可以用于gdb调试的有用信息。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

    3.3 nm

    使用nm命令列出二进制文件中的符号表,包括符号地址、符号类型、符号名等,这样可以帮助定位在哪里发生了段错误。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ nm segfault3
    08049f20 d _DYNAMIC
    08049ff4 d _GLOBAL_OFFSET_TABLE_
    080484dc R _IO_stdin_used
             w _Jv_RegisterClasses
    08049f10 d __CTOR_END__
    08049f0c d __CTOR_LIST__
    08049f18 D __DTOR_END__
    08049f14 d __DTOR_LIST__
    080484ec r __FRAME_END__
    08049f1c d __JCR_END__
    08049f1c d __JCR_LIST__
    0804a014 A __bss_start
    0804a00c D __data_start
    08048490 t __do_global_ctors_aux
    08048360 t __do_global_dtors_aux
    0804a010 D __dso_handle
             w __gmon_start__
    0804848a T __i686.get_pc_thunk.bx
    08049f0c d __init_array_end
    08049f0c d __init_array_start
    08048420 T __libc_csu_fini
    08048430 T __libc_csu_init
             U __libc_start_main@@GLIBC_2.0
    0804a014 A _edata
    0804a01c A _end
    080484bc T _fini
    080484d8 R _fp_hw
    080482bc T _init
    08048330 T _start
    0804a014 b completed.6990
    0804a00c W data_start
    0804a018 b dtor_idx.6992
    080483c0 t frame_dummy
    080483e4 T main
             U memcpy@@GLIBC_2.0

    3.4 ldd

    使用ldd命令查看二进制程序的共享链接库依赖,包括库的名称、起始地址,这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。以程序2.3为例:

    panfeng@ubuntu:~/segfault$ ldd ./segfault3
        linux-gate.so.1 =>  (0x00e08000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00675000)
        /lib/ld-linux.so.2 (0x00482000)

    4. 段错误的调试方法

    4.1 使用printf输出信息

    这个是看似最简单但往往很多情况下十分有效的调试方式,也许可以说是程序员用的最多的调试方式。简单来说,就是在程序的重要代码附近加上像printf这类输出信息,这样可以跟踪并打印出段错误在代码中可能出现的位置。

    为了方便使用这种方法,可以使用条件编译指令#ifdef DEBUG和#endif把printf函数包起来。这样在程序编译时,如果加上-DDEBUG参数就能查看调试信息;否则不加该参数就不会显示调试信息。

    4.2 使用gcc和gdb

    4.2.1 调试步骤

     1、为了能够使用gdb调试程序,在编译阶段加上-g参数,以程序2.3为例:

    panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

    2、使用gdb命令调试程序:

    panfeng@ubuntu:~/segfault$ gdb ./segfault3 
    GNU gdb (GDB) 7.0-ubuntu
    Copyright (C) 2009 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 "i486-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /home/panfeng/segfault/segfault3...done.
    (gdb) 

    3、进入gdb后,运行程序:

    (gdb) run
    Starting program: /home/panfeng/segfault/segfault3 
    
    Program received signal SIGSEGV, Segmentation fault.
    0x001a306a in memcpy () from /lib/tls/i686/cmov/libc.so.6
    (gdb) 

    从输出看出,程序2.3收到SIGSEGV信号,触发段错误,并提示地址0x001a306a、调用memcpy报的错,位于/lib/tls/i686/cmov/libc.so.6库中。

    4、完成调试后,输入quit命令退出gdb:

    (gdb) quit
    A debugging session is active.
    
        Inferior 1 [process 3207] will be killed.
    
    Quit anyway? (y or n) y

    4.2.2 适用场景

    1、仅当能确定程序一定会发生段错误的情况下使用。

    2、当程序的源码可以获得的情况下,使用-g参数编译程序。

    3、一般用于测试阶段,生产环境下gdb会有副作用:使程序运行减慢,运行不够稳定,等等。

    4、即使在测试阶段,如果程序过于复杂,gdb也不能处理。

    4.3 使用core文件和gdb

    在4.2节中提到段错误会触发SIGSEGV信号,通过man 7 signal,可以看到SIGSEGV默认的handler会打印段错误出错信息,并产生core文件,由此我们可以借助于程序异常退出时生成的core文件中的调试信息,使用gdb工具来调试程序中的段错误。

    4.3.1 调试步骤

    1、在一些Linux版本下,默认是不产生core文件的,首先可以查看一下系统core文件的大小限制:

    panfeng@ubuntu:~/segfault$ ulimit -c
    0

    2、可以看到默认设置情况下,本机Linux环境下发生段错误时不会自动生成core文件,下面设置下core文件的大小限制(单位为KB):

    panfeng@ubuntu:~/segfault$ ulimit -c 1024
    panfeng@ubuntu:~/segfault$ ulimit -c
    1024

    3、运行程序2.3,发生段错误生成core文件:

    panfeng@ubuntu:~/segfault$ ./segfault3
    段错误 (core dumped)

    4、加载core文件,使用gdb工具进行调试:

    panfeng@ubuntu:~/segfault$ gdb ./segfault3 ./core 
    GNU gdb (GDB) 7.0-ubuntu
    Copyright (C) 2009 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 "i486-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /home/panfeng/segfault/segfault3...done.
    
    warning: Can't read pathname for load map: 输入/输出错误.
    Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
    Loaded symbols for /lib/tls/i686/cmov/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
    Loaded symbols for /lib/ld-linux.so.2
    Core was generated by `./segfault3'.
    Program terminated with signal 11, Segmentation fault.
    #0  0x0018506a in memcpy () from /lib/tls/i686/cmov/libc.6

    从输出看出,同4.2.1中一样的段错误信息。

    5、完成调试后,输入quit命令退出gdb:

    (gdb) quit

    4.3.2 适用场景

    1、适合于在实际生成环境下调试程序的段错误(即在不用重新发生段错误的情况下重现段错误)。

    2、当程序很复杂,core文件相当大时,该方法不可用。

    4.4 使用objdump

    4.4.1 调试步骤

    1、使用dmesg命令,找到最近发生的段错误输出信息:

    panfeng@ubuntu:~/segfault$ dmesg
    ... ...
    [17257.502808] segfault3[3320]: segfault at 80484e0 ip 0018506a sp bfc1cd6c error 7 in libc-2.10.1.so[110000+13e000]

    其中,对我们接下来的调试过程有用的是发生段错误的地址:80484e0和指令指针地址:0018506a。

    2、使用objdump生成二进制的相关信息,重定向到文件中:

    panfeng@ubuntu:~/segfault$ objdump -d ./segfault3 > segfault3Dump

    其中,生成的segfault3Dump文件中包含了二进制文件的segfault3的汇编代码。

    3、在segfault3Dump文件中查找发生段错误的地址:

    panfeng@ubuntu:~/segfault$ grep -n -A 10 -B 10 "80484e0" ./segfault3Dump 
    121- 80483df:    ff d0                    call   *%eax
    122- 80483e1:    c9                       leave  
    123- 80483e2:    c3                       ret    
    124- 80483e3:    90                       nop
    125-
    126-080483e4 <main>:
    127- 80483e4:    55                       push   %ebp
    128- 80483e5:    89 e5                    mov    %esp,%ebp
    129- 80483e7:    83 e4 f0                 and    $0xfffffff0,%esp
    130- 80483ea:    83 ec 20                 sub    $0x20,%esp
    131: 80483ed:    c7 44 24 1c e0 84 04     movl   $0x80484e0,0x1c(%esp)
    132- 80483f4:    08 
    133- 80483f5:    b8 e5 84 04 08           mov    $0x80484e5,%eax
    134- 80483fa:    c7 44 24 08 05 00 00     movl   $0x5,0x8(%esp)
    135- 8048401:    00 
    136- 8048402:    89 44 24 04              mov    %eax,0x4(%esp)
    137- 8048406:    8b 44 24 1c              mov    0x1c(%esp),%eax
    138- 804840a:    89 04 24                 mov    %eax,(%esp)
    139- 804840d:    e8 0a ff ff ff           call   804831c <memcpy@plt>
    140- 8048412:    c9                       leave  
    141- 8048413:    c3                       ret    

    通过对以上汇编代码分析,得知段错误发生main函数,对应的汇编指令是movl $0x80484e0,0x1c(%esp),接下来打开程序的源码,找到汇编指令对应的源码,也就定位到段错误了。

    4.4.2 适用场景

    1、不需要-g参数编译,不需要借助于core文件,但需要有一定的汇编语言基础。

    2、如果使用了gcc编译优化参数(-O1,-O2,-O3)的话,生成的汇编指令将会被优化,使得调试过程有些难度。

    4.5 使用catchsegv

    catchsegv命令专门用来扑获段错误,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的库(/lib/libSegFault.so)加载上,用于捕捉断错误的出错信息。

    panfeng@ubuntu:~/segfault$ catchsegv ./segfault3
    Segmentation fault (core dumped)
    *** Segmentation fault
    Register dump:
    
     EAX: 00000000   EBX: 00fb3ff4   ECX: 00000002   EDX: 00000000
     ESI: 080484e5   EDI: 080484e0   EBP: bfb7ad38   ESP: bfb7ad0c
    
     EIP: 00ee806a   EFLAGS: 00010203
    
     CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b
    
     Trap: 0000000e   Error: 00000007   OldMask: 00000000
     ESP/signal: bfb7ad0c   CR2: 080484e0
    
    Backtrace:
    /lib/libSegFault.so[0x3b606f]
    ??:0(??)[0xc76400]
    /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xe89b56]
    /build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8048351]
    
    Memory map:
    
    00258000-00273000 r-xp 00000000 08:01 157 /lib/ld-2.10.1.so
    00273000-00274000 r--p 0001a000 08:01 157 /lib/ld-2.10.1.so
    00274000-00275000 rw-p 0001b000 08:01 157 /lib/ld-2.10.1.so
    003b4000-003b7000 r-xp 00000000 08:01 13105 /lib/libSegFault.so
    003b7000-003b8000 r--p 00002000 08:01 13105 /lib/libSegFault.so
    003b8000-003b9000 rw-p 00003000 08:01 13105 /lib/libSegFault.so
    00c76000-00c77000 r-xp 00000000 00:00 0 [vdso]
    00e0d000-00e29000 r-xp 00000000 08:01 4817 /lib/libgcc_s.so.1
    00e29000-00e2a000 r--p 0001b000 08:01 4817 /lib/libgcc_s.so.1
    00e2a000-00e2b000 rw-p 0001c000 08:01 4817 /lib/libgcc_s.so.1
    00e73000-00fb1000 r-xp 00000000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb1000-00fb2000 ---p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb2000-00fb4000 r--p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb4000-00fb5000 rw-p 00140000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so
    00fb5000-00fb8000 rw-p 00000000 00:00 0
    08048000-08049000 r-xp 00000000 08:01 303895 /home/panfeng/segfault/segfault3
    08049000-0804a000 r--p 00000000 08:01 303895 /home/panfeng/segfault/segfault3
    0804a000-0804b000 rw-p 00001000 08:01 303895 /home/panfeng/segfault/segfault3
    09432000-09457000 rw-p 00000000 00:00 0 [heap]
    b78cf000-b78d1000 rw-p 00000000 00:00 0
    b78df000-b78e1000 rw-p 00000000 00:00 0
    bfb67000-bfb7c000 rw-p 00000000 00:00 0 [stack]

    5. 一些注意事项

    1、出现段错误时,首先应该想到段错误的定义,从它出发考虑引发错误的原因。

    2、在使用指针时,定义了指针后记得初始化指针,在使用的时候记得判断是否为NULL。

    3、在使用数组时,注意数组是否被初始化,数组下标是否越界,数组元素是否存在等。

    4、在访问变量时,注意变量所占地址空间是否已经被程序释放掉。

    5、在处理变量时,注意变量的格式控制是否合理等。

    6. 参考资料列表

    1、http://www.docin.com/p-105923877.html

    2、http://blog.chinaunix.net/space.php?uid=317451&do=blog&id=92412




    http://qgjie456.blog.163.com/blog/static/35451367201112722827742/

    一、 段错误原因分析
             1 使用非法的指针,包括使用未经初始化及已经释放的指针(指针使用之前和释放之后置为NULL)
             2 内存读/写越界。包括数组访问越界,或在使用一些写内存的函数时,长度指定不正确或者这些函数本身不能指定长度,典型的函数有strcpy(strncpy),sprintf(snprint)等等。
             3 对于C++对象,请通过相应类的接口来去内存进行操作,禁止通过其返回的指针对内存进行写操作,典型的如string类的data()和c_str()两个接口。
             4 函数不要返回其中局部对象的引用或地址,当函数返回时,函数栈弹出,局部对象的地址将失效,改写或读这些地址都会造成未知的后果。
             5 避免在栈中定义过大的数组,否则可能导致进程的栈空间不足,此时也会出现段错误。
             6 操作系统的相关限制,如:进程可以分配的最大内存,进程可以打开的最大文件描述符个数等,这些需要通过ulimit或setrlimit或sysctl来解除相关的限制。
             7 多线程的程序,涉及到多个线程同时操作一块内存时必须进行互斥,否则内存中的内存将不可预料
             8 使用非线程安全的函数调用,例如 strerror 函数等
             9 在有信号的环境中,使用不可重入函数调用,而这些函数内部会读或写某片内存区,当信号中断时,内存写操作将被打断,而下次进入时将不避免的出错。
             10 跨进程传递某个地址
            11 某些有特殊要求的系统调用,例如epool_wait,正常情况下使用close关闭一个套接字后,epool会不再返回这个socket上的事件,但是如果你使用dup或dup2操作,将导致epool无法进行移除操作。

    二、 段错误原因查找
    1) 查看函数调用栈

        在头文件"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);
         }
         free (strings);
    }

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

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

    备注:void *const *buffer -- buffer指向char类型的常量指针的指针(很是拗口)

    2) 查看寄存器内容
    要查看寄存器内容有两个解决办法:

    A) 在内核里面把这些寄存器打印出来;

          

        段错误原因分析和查找 - ququ - linux 学习

           一:段错误时内核执行路径

    根据上图,我们只需要在__do_user_fault的时候把打印信息打开就可以了,如下:

    #ifdef CONFIG_DEBUG_USER

           if (user_debug & UDBG_SEGV) {

                  printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                         tsk->comm, sig, addr, fsr);

                  show_pte(tsk->mm, addr);

                  show_regs(regs);

           }

    #endif

    改成

    printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                         tsk->comm, sig, addr, fsr);

                  show_pte(tsk->mm, addr);

                  show_regs(regs);

    就可以了;

          里面会打印出pc寄存器的值。

    B) 在上层程序里面把寄存器打印出来;


    这个做法的主要思路就是先拦截SIGSEGV信号,然后在信号处理函数里面打印信息:

    信号拦截代码如下:

    static void  catch_sigsegv()

    {

           struct sigaction action;

           memset(&action, 0, sizeof(action));

           action.sa_sigaction = sigsegv_handler;

           action.sa_flags = SA_SIGINFO;       // 注意这里,flag 是 SA_SIGINFO,这样信号处理函数就会多一些信息。

           if(sigaction(SIGSEGV, &action, NULL) < 0){

                  perror("sigaction");

    }

    }

    只需要在main函数里面加入这个函数就可以了,

    main(…)

    {

    ….

    catch_sigsegv();

    }

     

    下面来看看这个处理函数sigsegv_handler是怎么写的,代码如下:

    #include <memory.h>

    #include <stdlib.h>

    #include <stdio.h>

    #include <unistd.h>

    #include <signal.h>

    #include <ucontext.h>

    #include <dlfcn.h>

    static void sigsegv_handler(int signum, siginfo_t* info, void*ptr)

    {

            static const char *si_codes[3] = {"", "SEGV_MAPERR", "SEGV_ACCERR"};

            int i;

            ucontext_t *ucontext = (ucontext_t*)ptr;

            void *bt[100];

            char **strings;


            printf("Segmentation Fault Trace:\n");

            printf("info.si_signo = %d\n", signum);

            printf("info.si_errno = %d\n", info->si_errno);

            printf("info.si_code  = %d (%s)\n", info->si_code, si_codes[info->si_code]);

            printf("info.si_addr  = %p\n", info->si_addr);

     

            /*for arm*/

            printf("the arm_fp 0x%3x\n",ucontext->uc_mcontext.arm_fp);

            printf("the arm_ip 0x%3x\n",ucontext->uc_mcontext.arm_ip);

            printf("the arm_sp 0x%3x\n",ucontext->uc_mcontext.arm_sp);

            printf("the arm_lr 0x%3x\n",ucontext->uc_mcontext.arm_lr);

            printf("the arm_pc 0x%3x\n",ucontext->uc_mcontext.arm_pc);

            printf("the arm_cpsr 0x%3x\n",ucontext->uc_mcontext.arm_cpsr);

            printf("the falut_address 0x%3x\n",ucontext->uc_mcontext.fault_address);

     

            printf("Stack trace (non-dedicated):");

            int sz = backtrace(bt, 20);

            printf("the stack trace is %d\n",sz);

            strings = backtrace_symbols(bt, sz);

            for(i = 0; i < sz; ++i){

                    printf("%s\n", strings[i]);

            }

        _exit (-1);

    }

     

     

    测试代码如下:

    void test_segv()

    {

            char *i=0;

            *i=10;

    }

     

    void cause_segv()

    {

            printf("this is the cause_segv\n");

            test_segv();

    }

    int main(int argc,char **argv)

    {

            catch_sigsegv();

            cause_segv();

            return 0;

    }

    编译方法:

    gcc segment_trace.c -g –rdynamic –o segment_trace

    执行:

    ./segment_trace

    输出如下:

    this is the catch_sigsegv

    Segmentation Fault Trace:

    info.si_signo = 11

    info.si_errno = 0

    info.si_code  = 1 (SEGV_MAPERR)

    info.si_addr  = (nil)

    the arm_fp 0xb7f8a3d4

    the arm_ip 0xb7f8a3d8

    the arm_sp 0xb7f8a3c0

    the arm_lr 0x8998

    the arm_pc 0x8974

    the arm_cpsr 0x60000010

    the falut_address 0x  0

    Stack trace (non-dedicated):the stack trace is 5

    ./segment_trace(backtrace_symbols+0x1c8) [0x8844]

    /lib/libc.so.6(__default_rt_sa_restorer+0) [0xb5e22230]

    ./segment_trace(cause_segv+0x18) [0x8998]

    ./segment_trace(main+0x20) [0x89c0]

    /lib/libc.so.6(__libc_start_main+0x108) [0xb5e0c10c]


        C) 输出信息分析 

    根据上面的输出可以看出一些端倪:

    根据栈信息,可以看出是在cause_segv里面出了问题,但是最后一层栈信息是看不到的,另外需要根据pc寄存器的值来定位:

    addr2line  -f -e segment_trace 0x8974

    test_segv

    /home/wf/test/segment_trace.c:55

    可以看到说是在55行,一看:

    刚好是

    *i=10;

    这一行,

    而且可以看出,函数名是test_segv

    所以基本上不需要打印栈信息,也可以定位了。

    也可以使用 objdump 工具:

    objdump -S -l -z  -j .text segment_trace   >1.txt

    查看 0x8974 地址的代码。



    http://baike.baidu.com/link?url=-xg1OCMI1mu87OU0zuI4yxKur5TN4J6Rt4-ApMqawO7cWUobl62xYS3EfcxqE9REbGIMic3mynwSq4-4qp4y_K

    百度百科上关于段错误的资料。


    http://wenku.baidu.com/link?url=waqeLu5VaUVyO0GuogoykFwv2EACmiQBBHElpce56DoXtlwIGfPsQFmOjI7s-GFlSx8mJaviBwUSaTsM7etQ77ykcCeNP2KOnpe6HCRTtqW


    展开全文
  • Linux下段错误原因以及调试方法

    千次阅读 2016-11-20 19:50:24
    简而言之,产生段错误就是 访问了错误的内存段 。 一、一般来说,段错误就是指访问的内存超出了系统分配给这个程序的内存空间,通常这个值是由gdtr来保存的, 1)gdtr是一个48位的寄存器,其中的32位是保 存由它...
  • 转载至:http://www.cnblogs.com/panfeng412/archive/2011/11/06/segmentation-fault-in-linux.html ... 1. 段错误是什么 ...一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例
  • 因为你调用了glibc的fputs ...同学们在做Linux练习的时候,编译完程序,执行的时候,有时会莫名的出现 “Segment fault”,即段错误段错误是让许多C程序员都头疼的提示,因为对于这种模糊的提示,很难判断错误在哪里
  • 段错误 就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址.  一 般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来保存的是...
  • SpringBoot+Shiro引起事务失效、错误原因、解决方法

    千次阅读 多人点赞 2018-07-25 10:41:49
    然而事务失效都不是这些原因引起的,并且发现其他Service的事务都可以正常使用。在查看打印的异常调用链的时候,发现这个Service是没有被AOP代理过的,所以推测可能是因为其他整合Spring的框架提前引用了这个Service...
  • 段错误总结

    万次阅读 多人点赞 2017-04-10 20:13:36
    最近试着写了华为编程大赛的程序,由于C++下编程还不熟练,出现较多的一个问题是段错误,结合网上资料总结下。 ...段错误是什么 一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存...段错误产生的原因
  • 产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址。 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来保存...
  • 产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址。 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来...
  • C语言再学习 -- 段错误(核心已转储)

    万次阅读 多人点赞 2016-12-21 12:22:57
    参看:Linux下的段错误产生的原因及调试方法参看:Linux环境下段错误的产生原因及调试方法小结参看:维基百科--Segmentation fault参看:LINUX内核段错误调试详细指南精品培训PPT讲义一、什么是段错误?一旦一个程序...
  • 牛客网编程提示“程序发生段错误,可能是数组越界,堆栈溢出(比如,递归调用层数太多)“的可能原因
  • Linux下的段错误(Segmentation fault)产生的原因及调试方法(经典)  简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址...
  • 有一设置或插件,阻止第方cookies积极将导致此错误。 Look in your browser setting and try setting it to allow third party cookies. 在您的浏览器设置,并尝试将其设置为允许第方Cookie ...
  • 项目中使用LPC1857单片机...在bootloader代码中我们使用了官方移植好的ucosIII系统,当检测到APP应用程序格式正确时,执行跳转功能,直接从IAP代码跳到APP代码中运行,但是跳转后在运行APP代码时MCU出现HardFault错误
  • 简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由...
  • Segmentation Fault错误原因总结

    万次阅读 多人点赞 2017-09-01 17:24:52
    一、 什么是“Segmentation fault in Linux”所谓的段错误就是指访问的内存超过了系统所给这个程序的内存空间,通常这个值是由gdtr来保存的,他是一个48位的寄存器,其中的32位是保存由它指向的gdt表,后13位保存...
  • c语言中常见的几个段错误

    万次阅读 2012-10-22 16:59:58
    例如,试图往一个只读文本段存储值就会引起段错误 (4)用完了堆栈或堆空间(虚拟内存虽然巨大但绝非无限)  以发生频率为序,最终可能导致段错误的常见编程错误是: 1. 坏指针值错误: 在指针赋值之前就用
  • 用gdb检查段错误(segment fault)

    千次阅读 2007-08-01 17:14:00
    简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来...
  • GDB调试命令以及GDB调试段错误

    万次阅读 2014-10-07 15:00:56
    下面将就以下的一个存在段错误的程序介绍几调试方法: 以下是程序代码  dummy_function(void)  2 {  3 unsigned char*ptr=0x00;  4 *ptr =0x00;  5  6 }  7 int main(void)  8 { ...
  • [转]PHP程序段错误分析

    千次阅读 2014-10-09 17:48:50
    域名解析没有超时,也就是说,段错误不是因为域名解析超时引起。 从backtrace继续往上看,最终离开libcurl.so, 进入libc.so, 调用gethostbyname2_r@@GLIBC_2.2.5。 再上面调用__nss_next2,这里其实是glibc的NSS...
  • 今天刷剑指offer”树的子结构“这道题的时候,出现了“程序发生段错误,可能是数组越界,堆栈溢出(比如,递归调用层数太多)"的问题。这个问题在我刷题过程中出现的还是比较多的,因此稍微总结一下最近碰到的几个点...
  • 段错误或段违规(segmentation violation)应该已经很清楚,之前有过一篇文章介绍过“段模型”。在一般硬件中,段错误是由于“内存管理单元”(负责支持虚拟内存的...一个小型的会引起段错误的程序如下:int *p = 0;*p

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 122,214
精华内容 48,885
关键字:

引起段错误的三种原因