段错误信息的获取和调试

时间  2019-11-21
标签 段错误 信息 获取 调试 繁體版
原文   原文链接

1、段错误信息的获取

程序发生段错误时，提示信息不多，下面有几种查看段错误的发生信息的途径。html

一、dmesg

dmesg 能够在应用程序崩溃时，显示内存中保存的相关信息。linux

以下所示，经过 dmesg 命令能够查看发生段错误的程序名称、引发段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误缘由等。程序员

root@#dmesg
[ 6357.422282] a.out[3044]: segfault at 806851c ip b75cd668 sp bf8b2100 error 4 in libc-2.15.so[b7559000+19f000]

二、-g

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

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

gdb的简单使用：编程

(gdb)l  列表（list）ubuntu

(gdb)r  执行（run）session

(gdb)n  下一个（next）函数

(gdb)q  退出（quit）工具

(gdb)p  输出（print）

(gdb)c  继续（continue）

(gdb)b 4 设置断点（break）

(gdb)d   删除断点（delete）

三、nm

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

root@# nm a.out


四、ldd

使用 ldd 命令查看二进制程序的共享连接库依赖，包括库的名称、起始地址，这样能够肯定段错误究竟是发生在了本身的程序中仍是依赖的共享库中。

root@t# ldd a.out

五、dbx

能够在dbx命令下运行程序，这样能够查看程序是否用完了堆栈

% dbx a.out
(dbx) catch SIGSEGV
(dbx) run
...
signal SEGV (segmentation violation in <some_routine> at 0xeff57708)
(dbx) where

若是如今能够看到调用链，那说明堆栈空间还未用完。可是若是是：

fetch at 0xeffe7a60 failed -- I/O error
(dbx)

那么堆栈可能已经用完。上面这个十六进制的数就是能够提取或映射的堆栈地址。
能够尝试在C-shell中调整堆栈段的大小限制。如下调整为10KB

limit stacksize 10

 


2、段错误信息的调试

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

#include <stdio.h>
 
int main (void)
{
    int *ptr = NULL;
    *ptr = 10;
    return 0;
}
输出结果：
段错误（核心已转储）

一、使用 printf 输出信息

这个是看似最简单，但每每不少状况下十分有效的调试方式，也许能够说是程序员用的最多的调试方式。

简单来讲，就是在程序的重要代码附近加上像 printf 这类输出信息，这样能够跟踪并打印出段错误在代码中可能出现的位置。

为了方便使用这种方法，可使用条件编译指令 #define DEBUG 和 #endif 把 printf 函数包起来。

这样在程序编译时，若是加上 -DDEBUG 参数就能够查看调试信息；不然不加上参数就不会显示调试信息。

二、使用 gcc 和 gdb

1）调试步骤

A、为了可以使用 gdb 调试程序，在编译阶段加上 -g 参数。

root@# gcc -g test.c

B、使用 gdb 命令调试程序

root@# gdb a.out 
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/tarena/project/c_test/a.out...done.
(gdb)

C、进入 gdb 后，运行程序

(gdb) r
Starting program: /home/tarena/project/c_test/a.out 
 
Program received signal SIGSEGV, Segmentation fault.
0x080483c4 in main () at test.c:6
6        *ptr = 10;
(gdb)

从输出看出，程序收到 SIGSEGV 信号，触发段错误，并提示地址 0x080483c四、建立了一个空指针，而后试图访问它的值（读值）。

能够经过man 7 signal查看SIGSEGV的信息

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

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

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

2）适用场景

A、仅当能肯定程序必定会发生段错误的状况下适用。

B、当程序的源码能够得到的状况下，使用 -g 参数编译程序

C、通常用于测试阶段，生产环境下 gdb 会有反作用：使程序运行减慢，运行不够稳定，等等。

D、即便在测试阶段，若是程序过于复杂，gdb 也不能处理。

三、使用 core 文件和 gdb

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

1）调试步骤

A、在一些Linux版本下，默认是不产生 core 文件的，首先能够查看一下系统 core 文件的大小限制：

root@# ulimit -c
0

B、能够看到默认设置状况下，本机Linux环境下发生段错误不会自动生成 core 文件，下面设置下 core 文件的大小限制（单位为KB）

root@# ulimit -c 1024
root@# ulimit -c 
1024

C、运行程序，发生段错误生成的 core 文件

root@# ./a.out 
段错误 (核心已转储)

D、加载 core 文件，使用 gdb 工具进行调试

root@ubuntu:/home/tarena/project/c_test# gdb a.out core 
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/tarena/project/c_test/a.out...done.
[New LWP 3491]
warning: Can't read pathname for load map: 输入/输出错误.
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x080483c4 in main () at test.c:6
6        *ptr = 10;
(gdb)

从输出看出，能够显示出异样的段错误信息

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

(gdb) q

2）适用场景

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

B、当程序很复杂，core 文件至关大时，该方法不可用

四、使用 objdump

1）调试步骤

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

root@# dmesg
[  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 生成二进制的相关信息，重定向到文件中

root@# objdump -d a.out > a.outDump 
root@# ls
a.out  a.outDump  core  test.c

其中，生成的 a.outDump 文件中包含了二进制文件的 a.out 的汇编代码

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

root@ubuntu:/home/tarena/project/c_test# grep -n -A 10 -B 10 "0" a.outDump
1-
2-a.out:     file format elf32-i386
 
118:080483b4 <main>:
119: 80483b4:    55                       push   %ebp
120: 80483b5:    89 e5                    mov    %esp,%ebp
121: 80483b7:    83 ec 10                 sub    $0x10,%esp
122: 80483ba:    c7 45 fc 00 00 00 00     movl   $0x0,-0x4(%ebp)
123: 80483c1:    8b 45 fc                 mov    -0x4(%ebp),%eax
124: 80483c4:    c7 00 0a 00 00 00        movl   $0xa,(%eax)
125: 80483ca:    b8 00 00 00 00           mov    $0x0,%eax
126: 80483cf:    c9                       leave  
127: 80483d0:    c3                       ret    
128: 80483d1:    90                       nop
129: 80483d2:    90                       nop
130: 80483d3:    90                       nop
131: 80483d4:    90                       nop
132: 80483d5:    90                       nop
133: 80483d6:    90                       nop
134: 80483d7:    90                       nop
135: 80483d8:    90                       nop
136: 80483d9:    90                       nop
137: 80483da:    90                       nop
138: 80483db:    90                       nop
139: 80483dc:    90                       nop
140: 80483dd:    90                       nop
141: 80483de:    90                       nop
142: 80483df:    90                       nop

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

2）适用场景

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

B、若是使用 gcc 编译优化参数（-O1，-O2，-O3）的话，生成的汇编指令将会被优化，使得调试过程有些难度。

五、使用catchsegv

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

root@t# catchsegv ./a.out
Segmentation fault (core dumped)
*** Segmentation fault
Register dump:
 EAX: 00000000   EBX: b77a1ff4   ECX: bfd8a0e4   EDX: bfd8a074
 ESI: 00000000   EDI: 00000000   EBP: bfd8a048   ESP: bfd8a038
 EIP: 080483c4   EFLAGS: 00010282
 CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b
 Trap: 0000000e   Error: 00000006   OldMask: 00000000
 ESP/signal: bfd8a038   CR2: 00000000
Backtrace:
??:0(main)[0x80483c4]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb761a4d3]
??:0(_start)[0x8048321]
Memory map:
08048000-08049000 r-xp 00000000 08:01 2102158 /home/tarena/project/c_test/a.out
08049000-0804a000 r--p 00000000 08:01 2102158 /home/tarena/project/c_test/a.out
0804a000-0804b000 rw-p 00001000 08:01 2102158 /home/tarena/project/c_test/a.out
09467000-0948c000 rw-p 00000000 00:00 0 [heap]
b75e1000-b75fd000 r-xp 00000000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1
b75fd000-b75fe000 r--p 0001b000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1
b75fe000-b75ff000 rw-p 0001c000 08:01 1704884 /lib/i386-linux-gnu/libgcc_s.so.1
b75ff000-b7601000 rw-p 00000000 00:00 0
b7601000-b77a0000 r-xp 00000000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so
b77a0000-b77a2000 r--p 0019f000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so
b77a2000-b77a3000 rw-p 001a1000 08:01 1704863 /lib/i386-linux-gnu/libc-2.15.so
b77a3000-b77a6000 rw-p 00000000 00:00 0
b77b8000-b77bb000 r-xp 00000000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so
b77bb000-b77bc000 r--p 00002000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so
b77bc000-b77bd000 rw-p 00003000 08:01 1704847 /lib/i386-linux-gnu/libSegFault.so
b77bd000-b77bf000 rw-p 00000000 00:00 0
b77bf000-b77c0000 r-xp 00000000 00:00 0 [vdso]
b77c0000-b77e0000 r-xp 00000000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so
b77e0000-b77e1000 r--p 0001f000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so
b77e1000-b77e2000 rw-p 00020000 08:01 1704843 /lib/i386-linux-gnu/ld-2.15.so
bfd6b000-bfd8c000 rw-p 00000000 00:00 0 [stack]

 

参考：
https://blog.csdn.net/qq_29350001/article/details/53780697

（C专家编程 7.7节）

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程