Linux上段错误(SegFault)的9种实用调试方法

已于 2024-01-25 20:45:08 修改
阅读量2.2k 收藏 36
点赞数 34
分类专栏： 程序调试 文章标签： linux c++ c语言
于 2024-01-12 12:08:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xzh203/article/details/135548102
版权

引言：什么是段错误

每个在Linux环境下工作的程序员，都遇到过段错误(segmentation fault)。

所谓段错误，本质上是程序访问了非法内存地址而引起的一种错误类型。

导致程序访问非法地址的原因有很多，如野指针、内存被踩、栈溢出、访问没有权限的内存等。

之前更新调试专题文章时，有朋友问到段错误的调试方法，我承诺会更新文章专门介绍，本文就是来填这个坑的。

本文将介绍9种非常实用的段错误调试方法。

1. 日志

日志是一种非常实用的调试手段，我们可以从系统日志中获得很多非常有用的信息，从而反推问题出现的前后系统中究竟发生了什么异常状况。

printf可能是最简单的日志记录方法，大家都懂的，不再赘述。

2. GDB

GDB的强大无需多言，对于段错误，利用GDB很容易就能定位到触发问题的那一行代码。如下图示例代码：

void test_3(int *p)
{
    *p = 1;
}

void test_2(int *p)
{
    test_3(p);
}

void test_1(int *p)
{
    test_2(p);
}

int main(int argc, char *argv[])
{
    int *p = (int *)0x12345678;

    test_1(p);
    return 0;
}

编译时加上-g选项：

gcc -g test.c -o test

在GDB中运行程序：

root@ubuntu:debug# gdb test
Reading symbols from test...
(gdb) r
Starting program: /opt/data/workspace/test/debug/test 

Program received signal SIGSEGV, Segmentation fault.
0x0000555555555139 in test_3 (p=0x12345678) at test.c:3
3           *p = 1;
(gdb) bt
#0  0x0000555555555139 in test_3 (p=0x12345678) at test.c:3
#1  0x000055555555515e in test_2 (p=0x12345678) at test.c:8
#2  0x000055555555517d in test_1 (p=0x12345678) at test.c:13
#3  0x00005555555551a7 in main (argc=1, argv=0x7fffffffe498) at test.c:20
(gdb)

段错误触发时，GDB会直接告诉我们问题出现在哪一行代码，并且可以利用backtrace命令查看完整调用栈信息。此外，还可以利用其他常规调试命令来查看参数、变量、内存等数据。

这种方式虽然非常有效，但很多时候，问题并不是100%必现的，我们不可能一直把程序运行在GDB中，这对程序的执行性能等会有很大的影响。

这时，我们可以让程序在异常终止时生成core dump文件，然后用调试工具对它进行离线调试。

3. Core Dump + GDB

Core dump是Linux提供的一种非常实用的程序调试手段，在程序异常终止时，Linux会把程序的上下文信息记录在一个core文件中，然后可以利用GDB等调试工具对core文件进行离线调试。

很多系统中，根据默认配置，程序异常退出时不会产生core dump文件。可以通过下面这条命令查看：

ulimit -c

如果值是0，则默认不会产生core dump文件。可以用下面命令设置生成core dump文件的大小：

ulimit -c 10240

上面命令把core dump文件大小设置为10MB。如果存储空间不受限的话，可以直接取消大小限制：

ulimit -c unlimited

然后重新运行示例程序，段错误触发后，默认会在当前目录下生产一个core文件：

root@ubuntu:debug# ./test
Segmentation fault (core dumped)
root@ubuntu:debug# ls
core-test-2113875-1705030770  test  test.c
root@ubuntu:debug#

然后用GDB加载调试core文件。调试时，除了core dump文件外，GDB还需要从可执行文件中加载调试信息。

gdb ./test ./core-test-2113875-1705030770

结果如下图：

root@ubuntu:debug# gdb ./test ./core-test-2113875-1705030770
Reading symbols from ./test...
[New LWP 2113875]
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055ccfa65b139 in test_3 (p=0x12345678) at test.c:3
3           *p = 1;
(gdb) bt
#0  0x000055ccfa65b139 in test_3 (p=0x12345678) at test.c:3
#1  0x000055ccfa65b15e in test_2 (p=0x12345678) at test.c:8
#2  0x000055ccfa65b17d in test_1 (p=0x12345678) at test.c:13
#3  0x000055ccfa65b1a7 in main (argc=1, argv=0x7ffeac135938) at test.c:20
(gdb)

与直接在GDB运行程序类似，core dump文件加载起来之后，GDB会直接显示触发问题的那一行代码，也可以使用backtrace、print等常规命令从core dump文件中获取信息。

在大多数系统中，这种core dump + GDB的手段非常有效，而且应该优先考虑使用。

但是有时候，由于某种原因，系统可能无法生存core dump文件。比如出于安全考虑，core dump功能可能是被彻底禁止的，或者在一些存储空间受限的嵌入式系统中，也无法生成core dump文件。

此时，我们就不得不考虑其它的调试手段了。

4. signal capture + backtrace

4.1 段错误在Linux系统上的处理过程

在Linux系统中，程序访问非法地址时，会被CPU捕获后触发硬件异常处理机制，并通知Linux kernel程序运行出现异常，kernel会对各种异常进行区分，然后向应用程序发送不同的signal，由应用程序自己进行故障恢复处理。

对于访问非法地址引起的段错误，Linux kernel会向应用程序发送11号signal，也就是SIGSEGV信号，该信号的默认处理是终止程序运行。

我们可以注册一个信号处理函数，当接受到Linux kernel发送过来的SIGSEGV信号后，在信号处理函数中把当前程序的上下文信息记录下来，方面后续问题定位。

4.2 两个有用的函数

int backtrace(void **buffer, int size);
void backtrace_symbols_fd(void *const *buffer, int size, int fd);

backtrace获取程序的调用栈地址信息，并存储在buffer指定的一个数组中，数组大小为size。

backtrace_symbols_fd根据backtrace得到的调用栈地址数据，获取地址对应的符号信息，并把结果写到fd指定的文件中。

4.3 示例

对上面的示例做下修改，增加一个信号处理函数，如下：

#define _GNU_SOURCE
#include <ucontext.h>
#include <stdio.h>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>

static void signal_handler(int sig, siginfo_t *info, void *ctx)
{
    ucontext_t *context = (ucontext_t *)ctx;

    /* dump registers, x64 CPU specific */
    printf( "Signal = %d  Memory location = %p\n"
            "RIP = %016X  RSP = %016X  RBP = %016X\n"
            "RAX = %016X  RBX = %016X  RCX = %016X\n"
            "RDX = %016X  RSI = %016X  RDI = %016X\n"
            "R8  = %016X  R9  = %016X  R10 = %016X\n"
            "R11 = %016X  R12 = %016X  R13 = %016X\n"
            "R14 = %016X  R15 = %016X  RFLAGS = %016X\n\n",
            sig, info->si_addr,
            context->uc_mcontext.gregs[REG_RIP],
            context->uc_mcontext.gregs[REG_RSP],
            context->uc_mcontext.gregs[REG_RBP],
            context->uc_mcontext.gregs[REG_RAX],
            context->uc_mcontext.gregs[REG_RBX],
            context->uc_mcontext.gregs[REG_RCX],
            context->uc_mcontext.gregs[REG_RDX],
            context->uc_mcontext.gregs[REG_RSI],
            context->uc_mcontext.gregs[REG_RDI],
            context->uc_mcontext.gregs[REG_R8],
            context->uc_mcontext.gregs[REG_R9],
            context->uc_mcontext.gregs[REG_R10],
            context->uc_mcontext.gregs[REG_R11],
            context->uc_mcontext.gregs[REG_R12],
            context->uc_mcontext.gregs[REG_R13],
            context->uc_mcontext.gregs[REG_R14],
            context->uc_mcontext.gregs[REG_R15],
            context->uc_mcontext.gregs[REG_EFL]);

    /* get call stack and write to stdout */
    void *buf[256] = {0};
    int size = backtrace(buf, 256);
    backtrace_symbols_fd(buf, size, fileno(stdout));
    exit(-1);
}

在信号处理函数signal_handler中，先把寄存器信息打印出来，然后用backtrace和backtrace_symbols_fd获取调用栈信息，并写入stdout。

然后，在main函数中注册SIGSEGV的信号处理函数，如下：

void test_3(int *p)
{
    *p = 1;
}

void test_2(int *p)
{
    test_3(p);
}

void test_1(int *p)
{
    test_2(p);
}

int main(int argc, char *argv[])
{
    int *p = 0x12345678;

    struct sigaction action;
    sigemptyset(&action.sa_mask);
    action.sa_sigaction = signal_handler;
    action.sa_flags = SA_SIGINFO;

    sigaction(SIGSEGV, &action, NULL);

    test_1(p);
    return 0;
}

编译一下：

gcc -g -rdynamic test1.c -o test1

看下运行结果：

root@ubuntu:debug# ./test1
Signal = 11  Memory location = 0x12345678
RIP = 000000008F57C44F  RSP = 0000000090348BF0  RBP = 0000000090348BF0
RAX = 0000000012345678  RBX = 000000008F57C540  RCX = 00000000BD0F7166
RDX = 0000000000000000  RSI = 0000000090348AE0  RDI = 0000000012345678
R8  = 0000000000000000  R9  = 0000000000000000  R10 = 0000000000000008
R11 = 0000000000000246  R12 = 000000008F57C140  R13 = 0000000090348DE0
R14 = 0000000000000000  R15 = 0000000000000000  RFLAGS = 0000000000010206

./test1(+0x1407)[0x555b8f57c407]
/lib/x86_64-linux-gnu/libc.so.6(+0x43090)[0x7f97bd0f7090]
./test1(test_3+0x10)[0x555b8f57c44f]
./test1(test_2+0x1c)[0x555b8f57c474]
./test1(test_1+0x1c)[0x555b8f57c493]
./test1(main+0x86)[0x555b8f57c51c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f97bd0d8083]
./test1(_start+0x2e)[0x555b8f57c16e]
root@ubuntu:debug#

为了方便演示，示例中的信号处理函数只记录了寄存器和调用栈信息，实际项目中根据需求，可以同时记录其它重要信息，如stack dump、全局变量、数据段dump等。

有两点需要注意：

  • 示例信号处理函数中打印寄存器的部分是针对x64 CPU的，其它CPU请参考sys/ucontext.h文件中对mcontext_t的定义。
  • 编译时需要加上-rdynamic选项，否则backtrace_symbols_fd无法正确获取符号信息。

5. signal capture + GDB

有些问题很难重现，直接在GDB里运行调试的话，可能要浪费很多时间去不停的尝试重现它。

那有没有一种方式，可以让问题重现时自动启动GDB呢？当然有！

与上面的一种方法类似，我们仍然利用signal capture的方式。只不过，在信号处理函数中，我们不再使用backtrace获取调用栈信息，而是直接启动GDB。

对信号处理函数作一些修改，如下：

static void signal_handler(int sig, siginfo_t *info, void *ctx)
{
    char cmd[256];

    printf("\n*** Segmentation fault happened, starting GDB ... \n\n");

    snprintf(cmd, 256, "gdb --pid=%d -ex bt -q", getpid());
    system(cmd);

    printf("\n*** Finish debugging, now quit! \n");
    exit(-1);
}

原理很简单，就是段错误发生时，在SIGSEGV信号处理函数中执行命令：

gdb --pid=xxx -ex bt -q

启动GDB，并attach到当前进程，然后执行backtrace命令打印调用栈信息。-q选项只是让GDB启动时不要打印版本信息，避免视觉干扰。

编译一下，需要加上-g选项：

gcc -g siggdb.c -o siggdb

运行，结果如下图：

root@ubuntu:debug# ./siggdb
attach: No such file or directory.
Attaching to process 2114093
Reading symbols from /opt/data/workspace/articles/debug/siggdb...
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f26e68f3c3a in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007f26e68f3c3a in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f26e6862f67 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000559bb65ff1fb in signal_handler (sig=11, info=0x7ffd8bbee570, ctx=0x7ffd8bbee440) at siggdb.c:16
#3  <signal handler called>
#4  0x0000559bb65ff211 in test_3 (p=0x12345678) at siggdb.c:23
#5  0x0000559bb65ff232 in test_2 (p=0x12345678) at siggdb.c:28
#6  0x0000559bb65ff24d in test_1 (p=0x12345678) at siggdb.c:33
#7  0x0000559bb65ff2d2 in main (argc=1, argv=0x7ffd8bbeebc8) at siggdb.c:47
(gdb)

注意：这种方法只能在测试环境中使用，且要确保GDB可以正常使用。生产环境中不要使用！

6. libSegFault.so

除了上面提到的几种方式外，其实glibc也已经很贴心地提供了一种问题定位的方案：libSegFault.so

libSegFault.so是glibc提供的一个动态链接库，用于捕捉程序运行异常并记录调用栈等调试信息。

它的实现原理和上面提到的第4种方法是一样的，即通过signal capture的方式，程序发生异常时，在信号处理函数中记录调试信息。

使用时，先确定系统中是否存在这个动态链接库。在我的系统中，有这么几个：

root@ubuntu:debug# find / -name libSegFault.so
/snap/snapd/20671/lib/x86_64-linux-gnu/libSegFault.so
/snap/snapd/20290/lib/x86_64-linux-gnu/libSegFault.so
/snap/core20/2105/usr/lib/i386-linux-gnu/libSegFault.so
/snap/core20/2105/usr/lib/x86_64-linux-gnu/libSegFault.so
/snap/core20/2015/usr/lib/i386-linux-gnu/libSegFault.so
/snap/core20/2015/usr/lib/x86_64-linux-gnu/libSegFault.so
/snap/core18/2812/lib/i386-linux-gnu/libSegFault.so
/snap/core18/2812/lib/x86_64-linux-gnu/libSegFault.so
/snap/core18/2796/lib/i386-linux-gnu/libSegFault.so
/snap/core18/2796/lib/x86_64-linux-gnu/libSegFault.so
/usr/lib32/libSegFault.so
/usr/lib/x86_64-linux-gnu/libSegFault.so
root@ubuntu:debug#

根据自己的实际情况，选择一个使用。比如我的测试环境是x64的，我选择使用：

/usr/lib/x86_64-linux-gnu/libSegFault.so

然后利用环境变量LD_PRELOAD，在测试程序运行前，把libSegFault.so链接进来。

LD_PRELOAD=/usr/lib/debug/lib/x86_64-linux-gnu/libSegFault.so   ./myapp

仍以本文第一个测试程序为例：

void test_3(int *p)
{
    *p = 1;
}

void test_2(int *p)
{
    test_3(p);
}

void test_1(int *p)
{
    test_2(p);
}

int main(int argc, char *argv[])
{
    int *p = 0x12345678;

    struct sigaction action;
    sigemptyset(&action.sa_mask);
    action.sa_sigaction = signal_handler;
    action.sa_flags = SA_SIGINFO;

    sigaction(SIGSEGV, &action, NULL);

    test_1(p);
    return 0;
}

编译：

gcc -rdynamic test.c -o test

运行：

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libSegFault.so ./test

测试程序触发段错误后，libSegFault.so中的信号处理函数会把寄存器、调用栈、内存映射全部dump出来。结果如下：

root@ubuntu:debug# LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libSegFault.so ./test
*** Segmentation fault
Register dump:

 RAX: 0000000012345678   RBX: 0000557bb87bb1b0   RCX: 0000557bb87bb1b0
 RDX: 00007fff1d833198   RSI: 00007fff1d833188   RDI: 0000000012345678
 RBP: 00007fff1d833030   R8 : 0000000000000000   R9 : 00007f61cdce9d60
 R10: 0000000000000008   R11: 0000000000000246   R12: 0000557bb87bb040
 R13: 00007fff1d833180   R14: 0000000000000000   R15: 0000000000000000
 RSP: 00007fff1d833030

 RIP: 0000557bb87bb139   EFLAGS: 00010202

 CS: 0033   FS: 0000   GS: 0000

 Trap: 0000000e   Error: 00000006   OldMask: 00000000   CR2: 12345678

 FPUCW: 0000037f   FPUSW: 00000000   TAG: 00000000
 RIP: 00000000   RDP: 00000000

 ST(0) 0000 0000000000000000   ST(1) 0000 0000000000000000
 ST(2) 0000 0000000000000000   ST(3) 0000 0000000000000000
 ST(4) 0000 0000000000000000   ST(5) 0000 0000000000000000
 ST(6) 0000 0000000000000000   ST(7) 0000 0000000000000000
 mxcsr: 1f80
 XMM0:  00000000000000000000000000000000 XMM1:  00000000000000000000000000000000
 XMM2:  00000000000000000000000000000000 XMM3:  00000000000000000000000000000000
 XMM4:  00000000000000000000000000000000 XMM5:  00000000000000000000000000000000
 XMM6:  00000000000000000000000000000000 XMM7:  00000000000000000000000000000000
 XMM8:  00000000000000000000000000000000 XMM9:  00000000000000000000000000000000
 XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000
 XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000
 XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000

Backtrace:
./test(+0x1139)[0x557bb87bb139]
./test(+0x115e)[0x557bb87bb15e]
./test(+0x117d)[0x557bb87bb17d]
./test(+0x11a7)[0x557bb87bb1a7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f61cdaf4083]
./test(+0x106e)[0x557bb87bb06e]

Memory map:

557bb87ba000-557bb87bb000 r--p 00000000 fc:10 550237                     /opt/data/workspace/test/debug/test
557bb87bb000-557bb87bc000 r-xp 00001000 fc:10 550237                     /opt/data/workspace/test/debug/test
557bb87bc000-557bb87bd000 r--p 00002000 fc:10 550237                     /opt/data/workspace/test/debug/test
557bb87bd000-557bb87be000 r--p 00002000 fc:10 550237                     /opt/data/workspace/test/debug/test
557bb87be000-557bb87bf000 rw-p 00003000 fc:10 550237                     /opt/data/workspace/test/debug/test
557bba6d5000-557bba6f6000 rw-p 00000000 00:00 0                          [heap]
7f61cdab2000-7f61cdab5000 r--p 00000000 fc:01 24328                      /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f61cdab5000-7f61cdac7000 r-xp 00003000 fc:01 24328                      /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f61cdac7000-7f61cdacb000 r--p 00015000 fc:01 24328                      /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f61cdacb000-7f61cdacc000 r--p 00018000 fc:01 24328                      /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f61cdacc000-7f61cdacd000 rw-p 00019000 fc:01 24328                      /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f61cdacd000-7f61cdad0000 rw-p 00000000 00:00 0 
7f61cdad0000-7f61cdaf2000 r--p 00000000 fc:01 17718                      /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f61cdaf2000-7f61cdc6a000 r-xp 00022000 fc:01 17718                      /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f61cdc6a000-7f61cdcb8000 r--p 0019a000 fc:01 17718                      /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f61cdcb8000-7f61cdcbc000 r--p 001e7000 fc:01 17718                      /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f61cdcbc000-7f61cdcbe000 rw-p 001eb000 fc:01 17718                      /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f61cdcbe000-7f61cdcc2000 rw-p 00000000 00:00 0 
7f61cdccf000-7f61cdcd0000 r--p 00000000 fc:01 17711                      /usr/lib/x86_64-linux-gnu/libSegFault.so
7f61cdcd0000-7f61cdcd3000 r-xp 00001000 fc:01 17711                      /usr/lib/x86_64-linux-gnu/libSegFault.so
7f61cdcd3000-7f61cdcd4000 r--p 00004000 fc:01 17711                      /usr/lib/x86_64-linux-gnu/libSegFault.so
7f61cdcd4000-7f61cdcd5000 r--p 00004000 fc:01 17711                      /usr/lib/x86_64-linux-gnu/libSegFault.so
7f61cdcd5000-7f61cdcd6000 rw-p 00005000 fc:01 17711                      /usr/lib/x86_64-linux-gnu/libSegFault.so
7f61cdcd6000-7f61cdcd8000 rw-p 00000000 00:00 0 
7f61cdcd8000-7f61cdcd9000 r--p 00000000 fc:01 17690                      /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f61cdcd9000-7f61cdcfc000 r-xp 00001000 fc:01 17690                      /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f61cdcfc000-7f61cdd04000 r--p 00024000 fc:01 17690                      /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f61cdd05000-7f61cdd06000 r--p 0002c000 fc:01 17690                      /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f61cdd06000-7f61cdd07000 rw-p 0002d000 fc:01 17690                      /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f61cdd07000-7f61cdd08000 rw-p 00000000 00:00 0 
7fff1d813000-7fff1d834000 rw-p 00000000 00:00 0                          [stack]
7fff1d967000-7fff1d96a000 r--p 00000000 00:00 0                          [vvar]
7fff1d96a000-7fff1d96b000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
Segmentation fault (core dumped)
root@ubuntu:debug#

libSegFault.so默认只捕捉SIGSEGV，可以通过设置环境变量SEGFAULT_SIGNALS指定要捕捉的信号，如：

export SEGFAULT_SIGNALS="all"  # "all" signals
export SEGFAULT_SIGNALS="segv bus abrt "  #SIGSEGV, SIGBUS and SIGABRT

环境变量SEGFAULT_USE_ALTSTACK可以指定是否让信号处理函数使用独立的栈，这在程序发送栈溢出时会很有用。

export SEGFAULT_USE_ALTSTACK=1

libSegFault.so默认把调试信息输出到stderr，可以通过设置环境变量SEGFAULT_OUTPUT_NAME，指定调试信息记录到一个文件中。比如：

export SEGFAULT_OUTPUT_NAME="./debug.log"

此外，为了方便用户使用，很多系统中还提供了一个名为catchsegv的脚本：

catchsegv ./test

其效果与通过LD_PRELOAD加载libSegFault.so是相同的：

root@ubuntu:debug# whereis catchsegv
catchsegv: /usr/bin/catchsegv /usr/share/man/man1/catchsegv.1.gz
root@ubuntu:debug# 
root@ubuntu:debug# catchsegv ./test
Segmentation fault (core dumped)
*** Segmentation fault
Register dump:

 RAX: 0000000012345678   RBX: 0000556c4e8d91b0   RCX: 0000556c4e8d91b0
 RDX: 00007ffdd20b2a68   RSI: 00007ffdd20b2a58   RDI: 0000000012345678
 RBP: 00007ffdd20b2900   R8 : 0000000000000000   R9 : 00007fdd23dc4d60
 R10: 00007fdd23daa730   R11: 00007fdd23d97be0   R12: 0000556c4e8d9040
 R13: 00007ffdd20b2a50   R14: 0000000000000000   R15: 0000000000000000
 RSP: 00007ffdd20b2900

 RIP: 0000556c4e8d9139   EFLAGS: 00010202

 CS: 0033   FS: 0000   GS: 0000

 Trap: 0000000e   Error: 00000006   OldMask: 00000000   CR2: 12345678

 FPUCW: 0000037f   FPUSW: 00000000   TAG: 00000000
 RIP: 00000000   RDP: 00000000

 ST(0) 0000 0000000000000000   ST(1) 0000 0000000000000000
 ST(2) 0000 0000000000000000   ST(3) 0000 0000000000000000
 ST(4) 0000 0000000000000000   ST(5) 0000 0000000000000000
 ST(6) 0000 0000000000000000   ST(7) 0000 0000000000000000
 mxcsr: 1f80
 XMM0:  00000000000000000000000000000000 XMM1:  00000000000000000000000000000000
 XMM2:  00000000000000000000000000000000 XMM3:  00000000000000000000000000000000
 XMM4:  00000000000000000000000000000000 XMM5:  00000000000000000000000000000000
 XMM6:  00000000000000000000000000000000 XMM7:  00000000000000000000000000000000
 XMM8:  00000000000000000000000000000000 XMM9:  00000000000000000000000000000000
 XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000
 XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000
 XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000

Backtrace:
./test(+0x1139)[0x556c4e8d9139]
./test(+0x115e)[0x556c4e8d915e]
./test(+0x117d)[0x556c4e8d917d]
./test(+0x11a7)[0x556c4e8d91a7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fdd23bcf083]
./test(+0x106e)[0x556c4e8d906e]

Memory map:

556c4e8d8000-556c4e8d9000 r--p 00000000 fc:10 550237 /opt/data/workspace/test/debug/test
556c4e8d9000-556c4e8da000 r-xp 00001000 fc:10 550237 /opt/data/workspace/test/debug/test
556c4e8da000-556c4e8db000 r--p 00002000 fc:10 550237 /opt/data/workspace/test/debug/test
556c4e8db000-556c4e8dc000 r--p 00002000 fc:10 550237 /opt/data/workspace/test/debug/test
556c4e8dc000-556c4e8dd000 rw-p 00003000 fc:10 550237 /opt/data/workspace/test/debug/test
556c4ead1000-556c4eaf2000 rw-p 00000000 00:00 0 [heap]
7fdd23b8d000-7fdd23b90000 r--p 00000000 fc:01 24328 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdd23b90000-7fdd23ba2000 r-xp 00003000 fc:01 24328 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdd23ba2000-7fdd23ba6000 r--p 00015000 fc:01 24328 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdd23ba6000-7fdd23ba7000 r--p 00018000 fc:01 24328 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdd23ba7000-7fdd23ba8000 rw-p 00019000 fc:01 24328 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdd23ba8000-7fdd23bab000 rw-p 00000000 00:00 0
7fdd23bab000-7fdd23bcd000 r--p 00000000 fc:01 17718 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fdd23bcd000-7fdd23d45000 r-xp 00022000 fc:01 17718 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fdd23d45000-7fdd23d93000 r--p 0019a000 fc:01 17718 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fdd23d93000-7fdd23d97000 r--p 001e7000 fc:01 17718 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fdd23d97000-7fdd23d99000 rw-p 001eb000 fc:01 17718 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fdd23d99000-7fdd23d9d000 rw-p 00000000 00:00 0
7fdd23daa000-7fdd23dab000 r--p 00000000 fc:01 17711 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fdd23dab000-7fdd23dae000 r-xp 00001000 fc:01 17711 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fdd23dae000-7fdd23daf000 r--p 00004000 fc:01 17711 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fdd23daf000-7fdd23db0000 r--p 00004000 fc:01 17711 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fdd23db0000-7fdd23db1000 rw-p 00005000 fc:01 17711 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fdd23db1000-7fdd23db3000 rw-p 00000000 00:00 0
7fdd23db3000-7fdd23db4000 r--p 00000000 fc:01 17690 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fdd23db4000-7fdd23dd7000 r-xp 00001000 fc:01 17690 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fdd23dd7000-7fdd23ddf000 r--p 00024000 fc:01 17690 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fdd23de0000-7fdd23de1000 r--p 0002c000 fc:01 17690 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fdd23de1000-7fdd23de2000 rw-p 0002d000 fc:01 17690 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fdd23de2000-7fdd23de3000 rw-p 00000000 00:00 0
7ffdd2093000-7ffdd20b4000 rw-p 00000000 00:00 0 [stack]
7ffdd21dd000-7ffdd21e0000 r--p 00000000 00:00 0 [vvar]
7ffdd21e0000-7ffdd21e1000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
root@ubuntu:debug#

7. Valgrind

Valgrind是一个很强大的工具集，它可以检测内存泄露、栈溢出、非法内存访问等多种内存相关的错误，还可以对程序进行性能剖析、生成函数调用关系图、统计Cache命中率、监测多线程竞争等，是程序调试的利器。

Valgrind功能非常强大，但文章篇幅有限，不对其展开讨论，后续会更新文章专门讲解它的各种功能，感兴趣的朋友可以右上角关注一下。

下面演示用Valgrind检测示例程序的内存访问错误。

编译时加上-g选项：

gcc -g test.c -o test

然后用Valgrind启动示例程序：

valgrind --tool=memcheck --leak-check=yes -v --leak-check=full --show-reachable=yes ./test

显示数据较多, 如下图所示：

root@ubuntu:debug# valgrind --tool=memcheck --leak-check=yes -v --leak-check=full --show-reachable=yes ./test
==2114522== Memcheck, a memory error detector
==2114522== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2114522== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info
==2114522== Command: ./test
==2114522== 
--2114522-- Valgrind options:
--2114522--    --tool=memcheck
--2114522--    --leak-check=yes
--2114522--    -v
--2114522--    --leak-check=full
--2114522--    --show-reachable=yes
--2114522-- Contents of /proc/version:
--2114522--   Linux version 5.4.0-90-generic (buildd@lgw01-amd64-054) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021
--2114522-- 
--2114522-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand
--2114522-- Page sizes: currently 4096, max supported 4096
--2114522-- Valgrind library directory: /usr/lib/x86_64-linux-gnu/valgrind
--2114522-- Reading syms from /opt/data/workspace/test/debug/test
--2114522-- Reading syms from /usr/lib/x86_64-linux-gnu/ld-2.31.so
--2114522--   Considering /usr/lib/debug/.build-id/7a/e2aaae1a0e5b262df913ee0885582d2e327982.debug ..
--2114522--   .. build-id is valid
--2114522-- Reading syms from /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux
--2114522--    object doesn't have a symbol table
--2114522--    object doesn't have a dynamic symbol table
--2114522-- Scheduler: using generic scheduler lock implementation.
--2114522-- Reading suppressions file: /usr/lib/x86_64-linux-gnu/valgrind/default.supp
==2114522== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2114522-by-root-on-???
==2114522== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-2114522-by-root-on-???
==2114522== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-2114522-by-root-on-???
==2114522== 
==2114522== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2114522== don't want to do, unless you know exactly what you're doing,
==2114522== or are doing some strange experiment):
==2114522==   /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=2114522 ...command...
==2114522== 
==2114522== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2114522==   /path/to/gdb ./test
==2114522== and then give GDB the following command
==2114522==   target remote | /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=2114522
==2114522== --pid is optional if only one valgrind process is running
==2114522== 
--2114522-- REDIR: 0x4022e20 (ld-linux-x86-64.so.2:strlen) redirected to 0x580c9ce2 (???)
--2114522-- REDIR: 0x4022bf0 (ld-linux-x86-64.so.2:index) redirected to 0x580c9cfc (???)
--2114522-- Reading syms from /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_core-amd64-linux.so
--2114522--    object doesn't have a symbol table
--2114522-- Reading syms from /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so
--2114522--    object doesn't have a symbol table
==2114522== WARNING: new redirection conflicts with existing -- ignoring it
--2114522--     old: 0x04022e20 (strlen              ) R-> (0000.0) 0x580c9ce2 ???
--2114522--     new: 0x04022e20 (strlen              ) R-> (2007.0) 0x0483f060 strlen
--2114522-- REDIR: 0x401f600 (ld-linux-x86-64.so.2:strcmp) redirected to 0x483ffd0 (strcmp)
--2114522-- REDIR: 0x4023380 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4843a20 (mempcpy)
--2114522-- Reading syms from /usr/lib/x86_64-linux-gnu/libc-2.31.so
--2114522--   Considering /usr/lib/debug/.build-id/ee/be5d5f4b608b8a53ec446b63981bba373ca0ca.debug ..
--2114522--   .. build-id is valid
--2114522-- REDIR: 0x48f7480 (libc.so.6:memmove) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6780 (libc.so.6:strncpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f77b0 (libc.so.6:strcasecmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f60a0 (libc.so.6:strcat) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f67e0 (libc.so.6:rindex) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f8c50 (libc.so.6:rawmemchr) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x4913ce0 (libc.so.6:wmemchr) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x4913820 (libc.so.6:wcscmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f75e0 (libc.so.6:mempcpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7410 (libc.so.6:bcmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6710 (libc.so.6:strncmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6150 (libc.so.6:strcmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7540 (libc.so.6:memset) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x49137e0 (libc.so.6:wcschr) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6670 (libc.so.6:strnlen) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6230 (libc.so.6:strcspn) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7800 (libc.so.6:strncasecmp) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f61d0 (libc.so.6:strcpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7950 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x4914f50 (libc.so.6:wcsnlen) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x4913860 (libc.so.6:wcscpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6820 (libc.so.6:strpbrk) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6100 (libc.so.6:index) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6630 (libc.so.6:strlen) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48ffbb0 (libc.so.6:memrchr) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7850 (libc.so.6:strcasecmp_l) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f73d0 (libc.so.6:memchr) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x4913930 (libc.so.6:wcslen) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f6ae0 (libc.so.6:strspn) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f7750 (libc.so.6:stpncpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f76f0 (libc.so.6:stpcpy) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f8c90 (libc.so.6:strchrnul) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x48f78a0 (libc.so.6:strncasecmp_l) redirected to 0x48311d0 (_vgnU_ifunc_wrapper)
--2114522-- REDIR: 0x49df730 (libc.so.6:__strrchr_avx2) redirected to 0x483ea10 (rindex)
==2114522== Invalid write of size 4
==2114522==    at 0x109139: test_3 (test.c:3)
==2114522==    by 0x10915D: test_2 (test.c:8)
==2114522==    by 0x10917C: test_1 (test.c:13)
==2114522==    by 0x1091A6: main (test.c:20)
==2114522==  Address 0x12345678 is not stack'd, malloc'd or (recently) free'd
==2114522== 
==2114522== 
==2114522== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==2114522==  Access not within mapped region at address 0x12345678
==2114522==    at 0x109139: test_3 (test.c:3)
==2114522==    by 0x10915D: test_2 (test.c:8)
==2114522==    by 0x10917C: test_1 (test.c:13)
==2114522==    by 0x1091A6: main (test.c:20)
==2114522==  If you believe this happened as a result of a stack
==2114522==  overflow in your program's main thread (unlikely but
==2114522==  possible), you can try to increase the size of the
==2114522==  main thread stack using the --main-stacksize= flag.
==2114522==  The main thread stack size used in this run was 8388608.
--2114522-- REDIR: 0x48f16d0 (libc.so.6:free) redirected to 0x483c9d0 (free)
==2114522== 
==2114522== HEAP SUMMARY:
==2114522==     in use at exit: 0 bytes in 0 blocks
==2114522==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2114522== 
==2114522== All heap blocks were freed -- no leaks are possible
==2114522== 
==2114522== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==2114522== 
==2114522== 1 errors in context 1 of 1:
==2114522== Invalid write of size 4
==2114522==    at 0x109139: test_3 (test.c:3)
==2114522==    by 0x10915D: test_2 (test.c:8)
==2114522==    by 0x10917C: test_1 (test.c:13)
==2114522==    by 0x1091A6: main (test.c:20)
==2114522==  Address 0x12345678 is not stack'd, malloc'd or (recently) free'd
==2114522== 
==2114522== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
root@ubuntu:debug#

Valgrind成功检测出地址0x12345678既不是栈地址，也不是malloc分配的动态内存。并且它也会把调用栈信息dump出来。

Valgrind虽然在检测内存相关的错误时非常强大，但是它有一个致命的缺点，就是慢。据统计，通过Valgrind运行程序时，速度会降低10倍。这在调试大型项目时，尤其是对实时性非常敏感的程序，是无法接受的。

不过，我们还有一个更好的选择 — AddressSanitizer。

8. AddressSanitizer

AddressSanitizer最初是Google开发的一个检测多种内存相关问题的工具，AddressSanitizer现在已经集成到GCC和LLVM中。它最大的特点是：

  • 功能强大。它可以检测内存泄露、访问越界、栈溢出、多次释放等各种内存问题。
  • 快。使用AddressSanitizer检测内存问题时，原始程序运行速度只会降低2倍左右，相比Vagrind来说，运行效率有了很大的提升。

本文只简单演示用AddressSanitizer检测示例程序中的内存访问错误，后续会专门更新文章详细讲解它的各种功能，感兴趣的朋友可以关注一下。

AddressSanitizer的使用方法也非常简单，只需要在编译时加上相应的编译选项，然后正常运行程序即可。

这里，我只使用最简单的一个编译选项-fsanitize=address开启AddressSanitizer功能。

gcc -g -fsanitize=address test.c -o test

然后正常运行即可，如下图：

root@ubuntu:debug# gcc -g -fsanitize=address test.c -o test
root@ubuntu:debug# ./test
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2114531==ERROR: AddressSanitizer: SEGV on unknown address 0x000012345678 (pc 0x55669475e1d4 bp 0x7ffcf6b43ad0 sp 0x7ffcf6b43ac0 T0)
==2114531==The signal is caused by a WRITE memory access.
    #0 0x55669475e1d3 in test_3 /opt/data/workspace/test/debug/test.c:3
    #1 0x55669475e1f8 in test_2 /opt/data/workspace/test/debug/test.c:8
    #2 0x55669475e217 in test_1 /opt/data/workspace/test/debug/test.c:13
    #3 0x55669475e241 in main /opt/data/workspace/test/debug/test.c:20
    #4 0x7f02b03ea082 in __libc_start_main ../csu/libc-start.c:308
    #5 0x55669475e0cd in _start (/opt/data/workspace/test/debug/test+0x10cd)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /opt/data/workspace/test/debug/test.c:3 in test_3
==2114531==ABORTING
root@ubuntu:debug#

9. dmesg + objdump

有时，可能由于各种原因，以上几种方法都不适用，比如程序中无法添加调试信息、程序无法重新编译、没有GDB和Valgrind等调试工具等。

这种情况下，调试起来，会相对比较困难一些，但也并不是完全不可能。

大多数情况下，程序发生segmentation fault而异常退出时，会在系统日志中记录一些信息，可以用dmesg查看：

root@ubuntu:debug# dmesg
[68302968.931073] test[2113875]: segfault at 12345678 ip 000055ccfa65b139 sp 00007ffeac1357e0 error 6 in test[55ccfa65b000+1000]
[68302968.931091] Code: 2e 00 00 01 5d c3 0f 1f 00 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa e9 77 ff ff ff f3 0f 1e fa 55 48 89 e5 48 89 7d f8 48 8b 45 f8 <c7> 00 01 00 00 00 90 5d c3 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 48
root@ubuntu:debug#

可以从中得到触发异常的指令地址和被访问的内存地址，然后利用系统中现有的一些工具进行调试，如利用objdump对可执行文件进行反汇编，然后从汇编代码入手进行分析，限于篇幅，不再展开讨论，后续会有专门文章详细讲解。

Linux下有很多非常有用的工具，如binutils工具集(objdump、nm、readelf等)、strace等，熟悉并善用这些工具，会事半功倍。

欢迎关注微信公众号：【原点技术】，分享真正有用的东西！

进技术交流群，欢迎添加作者微信：CreCoding

原创文章，未经允许禁止转载，转载请联系作者：CreCoding

原点技术
关注
  • 34
    点赞
  • 踩
  • 36
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Linux环境下段错误的产生原因及调试方法小结
12-26
最近在Linux环境下做C语言项目，由于是在一个原有项目基础之上进行二次开发，而且项目工程庞大复杂，出现了不少问题，其中遇到最多、花费时间最长的问题就是著名的“段错误”（Segmentation Fault）。借此机会系统学习了一下，这里对Linux环境下的段错误做个小结，方便以后同类问题的排查与解决。 1. 段错误是什么 一句话来说，段错误是指访问的内存超出了系统给这个程序所设定的内存空间，例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义（参考Answers.com）： A segmentation fault (ofte
Linux下分析进程segment fault的方法
To Be A Linux Graphics Coder
06-30 2717
长时间不用，命令容易忘，记录一下，以备忘． 1. 程序在编译时，记得加 -g　选项，以生成带符号表的目标程序． 2. 执行： sudo echo "core" &gt; /proc/sys/kernel/core_pattern　／／需要root权限．进程碰到段错误后，生成名为core的文件，并存放在进程同目录． ulimit -c unlimited 3. 段错误发生后，执行： ...
遇到segfault但是没有coredump文件如何定位问题？
InternalsOf
07-11 1567
生产环境定位问题往往遇到各种限制，比如事后日志发现程序是收到SIGSEGV退出了（segment fault），但是因为： 1. 没配置limit 2. 存储空间不够了 3. 其他未知原因 没有正常生成core文件，那么这会如何定位问题呢？...............
linux系统下产生Segmentation fault 与 Segmentation fault (core dumped)！！！
最新发布
m0_73537205的博客
05-07 2321
在Linux系统下，当程序不寻常退出时，内核会在当前工作目录下生成一个core文件（是一个内存映像，同时加上调试信息，编译时需要加上 -g -Wall）。我们使用gdb来查看core文件，可以指示出导致程序出错的代码所在文件和行数。如何生成core文件和大小限制当系统程序运行产生而不是显示这说明，并没有产生code文件，我们需要执行以下命令来生成code文件，并限制文件大小。使用ulimit -c命令查看core文件的生成开关，如果结果为0，则表示关闭了此功能，不会生成core文件。
linux--Segfault详解
天道酬勤
06-22 1万+
linux--Segfault详解1 简介2 知识点2.1 error number3 排除步骤参考 1 简介 2 知识点 2.1 error number 内核是通过show_signal_msg输出段错误信息的。 错误码是通过一个error_code的参数表示的，对应fault.c，发现如下内容： /* * Page fault error code bits: * * bit 0 == 0: no page found 1: protection fault * bit 1 ==
程序运行崩溃（segfault）的排查方法
热门推荐
bluish_white的博客
05-28 1万+
这篇博文记录的非常详细：https://blog.csdn.net/zhaohaijie600/article/details/45246569我的笔记：写的C++程序老是运行两三天就挂了，关键是挂的时候连“segment fault”都不显示。动用了gdb、valgrind还是没办法，最后还是根据系统的日志定位到了问题。首先，最好是在编译时加上debug选项（-g）。程序挂掉后，在终端通过指令d...
Linux下段错误总结
qq_53429771的博客
05-31 1388
用于学习记录。
一次segfault错误的排查过程
qq_34062754的博客
11-15 3116
一次segfault错误的排查过程 正常运行了几年的程序忽然崩溃了，由于机器没有设置CORE文件，无法从CORE中取得错误信息，程序运行在centOS 7上， 本来对centOS用的也是不熟，只能边查资料边查问题。 首先、我需要确认程序是否真的崩溃了，还是别人误操作关闭了。如果程序真的崩溃了，会在系统中留下痕迹，我查了一下，在messages文件中发现了一条信息： xxxxx.o[2374]: segfault at7f0ed0bfbf70 ip 00007f0edd646fe7 sp 00007f.
Python出现segfault错误解决方法
09-21
主要介绍了Python出现segfault错误解决方法,分析了系统日志提示segfault错误的原因与对应的解决方法,需要的朋友可以参考下
Linux C段错误定位
06-08
本文将探讨如何在Linux环境下，通过信号处理和调试技巧来定位C段错误。 首先，我们需要理解什么是SIGSEGV信号。当进程尝试访问其没有权限的内存区域时，操作系统会发送SIGSEGV信号给该进程，这就是段错误。在默认...
node-segfault-handler:调试本机Node.js模块并在出现问题时获取堆栈跟踪的工具
05-01
概述该模块是调试Node.js C / C ++本机代码模块的关键工具，可以在生产环境中安全使用。 通常，当在本机代码中触发错误时，节点进程只会以没有任何有用信息的方式结束。 在生产中，这似乎表现为工作进程似乎无缘无故...
SegFault Catch
08-30
在Linux上，可以使用`ulimit -c unlimited`设置核心转储，并用`gdb`加载来分析。 3. **编译器标志**：编译时添加`-g`选项可以包含调试信息，便于GDB使用。`-fsanitize`系列选项（如`-fsanitize=address`，`-...
Linux segfault错误排查
xiejianjun417的专栏
04-12 7620
Linux下一般情况程序出现段错误异常崩溃时，并不会产生core文件，此时可借助/var/log/messages中打印的错误信息进行排查。如下错误信息： segfault at 7f30beffe000 ip 00007f30c6eebda9 sp 00007f30a7ffc4a0 error 4 in libc-2.17.so[7f30c6e56000+1c3000] 其中，异常在libc-2.17.so库中，00007f30beffe000为出错地址，7f30c6eebda9为指令地址，00007
linux segfault at 问题定位实践
more_HH
03-09 1392
它指示崩溃发生在名为“mydefine.so”的共享库中，并且该库的基址为“7fb668d34000”，大小为“11000”字节。总体而言，此错误消息提供了一些用于调试崩溃的有用信息，包括发生故障的内存地址和指令指针、分段错误的类型以及发生崩溃时正在使用的共享库的名称和位置。生成独立的文件，用编辑工具打开来查看对应的1823c是属于哪一个函数，然后打开源码进行对应，定位是哪一个函数的哪一行出现的问题。这里仅仅使用了ip和so的基地址，其他的内存和sp地址信息暂未使用。偏移地址= 指令指针 - 库的基地址。
Linux下程序产生“段错误”的原因及其解决办法
chenzhjlf的专栏
05-04 6176
Linux下程序产生“段错误”的原因及其解决办法 产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存，尤其常见的是访问0地址。 一般来说，段错误就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，它是一个48位的寄存器，其中的32位是保 存由它指向的gdt表，后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序在cpu中的运行级别，指向的gdt是以64位为一个单 位的表，在这张表中就保存...
記憶體區段錯誤（英語：，經常被縮寫為segfault），又譯為記憶體段错误，也稱存取權限衝突（access violation），是一種程式錯誤。
weixin_40191861的博客
10-31 106
当程序试图访问不允许访问的内存位置，或试图以不允许的方式访问内存位置（例如，尝试写入只读位置，或覆盖操作系统的一部分）时，会产生储存器段错误。术语“分段”在计算中有多种用途；“储存器段错误”是自1950年代以来就一直使用的术语。当有内存保护时，只有程序自己的地址空间是可读的，其中只有堆栈和程序数据段的可读写部分是可写的，而只读数据和代码段是不可写的。因此，尝试读取程序地址空间之外的数据或写入至只读内存段时，会导致储存器段错误。
没有core文件时定位segfault at 0 ip 的问题（一）
哦，原来你也在这里。
07-28 4587
C/C++编写的程序，崩溃后有时不能生成core文件（即使设置了ulimited)，所以往往不知道发生了什么事情，生产环境根本不允许研发小朋友去调试，日志有时候看不出问题了。（如果生成了core文件，或通过日志能定位到问题所以，则可略过此文章）。 本文章专门针对于没有生成core文件、不能通过日志分析问题的情况 首先，写一段测试代码吧，不用怀疑，这段代码肯定是有问题的 #include <iostream> #include <cstdio> #include <mem
segfault信息分析:segfault at a ip 00007f4220309664 sp 00007fff580042b0 error 4 in librt-2.17.so[7f422030
白袍小将的博客
11-30 1072
linux有一个工具 addr2line命令，可以帮助定位排查segfault，本文示例了如何使用这种技术来定位访问违规的问题。
ubuntu 段错误 系统日志
05-29
Ubuntu 发生段错误的问题通常是由于程序访问了非法的内存地址所导致的，可能是由于编程问题或者硬件故障引起的。在系统日志中查看段错误的信息，可以提供一些有用的信息来帮助定位问题。 要查看系统日志，可以使用以下命令： ``` sudo tail -f /var/log/syslog ``` 这将输出最新的系统日志信息。如果发生了段错误，你将看到类似于以下的信息： ``` kernel: [12345.67890] program_name[1234]: segfault at 0 ip 000000000040052d sp 00007fffdcc4b430 error 4 in program_name[400000+1000] ``` 其中，program_name 是发生段错误的程序的名称，ip 是程序访问了非法地址的内存地址，sp 是程序堆栈指针的地址，error 是错误代码，表示访问了非法地址。 根据这些信息，你可以尝试定位程序的问题，并尝试解决它。如果无法解决问题，你可能需要与程序的开发者联系以获取帮助。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值