Linux SIGSEGV 是段错误信号，核心原因是程序访问了非法内存地址；解决它最直接的方法是开启 core dump 并用 GDB 回溯调用栈，找到具体出错的代码行。
linux sigsegv 的常见原因有哪些
SIGSEGV 在 Linux 系统里几乎每天都会出现，尤其是用 C/C++ 写底层服务或嵌入式程序时，它不是一个错误类型，而是一个信号，内核在检测到进程进行非法内存访问时发送给进程，理解它的触发条件,才能高效排查。
空指针解引用
这是最常见的一种，指针没有初始化，或者被赋值为 NULL,然后你对它做了读写操作。
int p = NULL; p = 10;
运行时内核发现你试图访问 0 地址，直接发 SIGSEGV，在 Linux 服务器 运维中，这类问题往往在压力测试时才暴露,因为某些分支在特定路径下才会触发空指针。
数组越界访问
C 和 C++ 不会自动检查数组边界，你写了一个长度为 10 的数组，却访问了第 11 个元素，这个位置可能属于其他变量或者元数据，写入后轻则数据错乱，重则立即崩溃，统计显示，相当一部分线上 Linux 程序崩溃都与数组越界有关，尤其是字符串操作时忘记预留结尾的 ‘ ’。
访问已释放的内存
使用 free 或 delete 释放堆内存后，指针仍然指向原地址（悬空指针），如果后续代码继续通过这个指针读写，内核可能已经把那块内存映射给其他模块，甚至已经回收了物理页，此时访问会触发 SIGSEGV，而且这种问题非常难复现，属于典型的“野指针”场景。
栈溢出
递归函数没有终止条件，或者局部变量占用过多栈空间（比如声明了一个超大的数组），都会导致栈溢出，内核检测到栈指针超出限制后，会发送 SIGSEGV，在嵌入式 Linux 开发中，因为栈空间通常较小,这个问题更常见。
非法指令或对齐错误
现代 CPU 对内存访问有对齐要求，比如访问 4 字节整数时地址必须是 4 的倍数，如果程序试图访问非对齐地址，某些架构（如 ARM）会直接触发 SIGSEGV，如果代码段被意外改写，CPU 尝试执行乱码，也会出现 SIGSEGV。
如何用 GDB 调试 linux sigsegv 信号
当程序崩溃时，不要直接重启，而是先收集现场信息，GDB 是应对 Linux 段错误最核心的工具。
开启 core dump 文件
系统默认可能不生成 core dump,需要手动设置。
ulimit -c unlimited # 当前 shell 生效 echo '/tmp/core.%p' > /proc/sys/kernel/core_pattern
这样程序崩溃时会在 /tmp 下生成带 pid 的 core 文件，注意，如果程序运行在 Docker 容器或云服务器上，需要确认系统是否允许 core dump,有些运维环境会默认关闭以节省磁盘。
用 GDB 加载 core 文件
gdb /path/to/program /tmp/core.12345
进入 GDB 后直接输入 bt（backtrace），就能看到崩溃时的调用堆栈，每一行对应一个函数调用，最上面是出错的函数，如果代码没有 strip 符号,还会显示具体行号。
定位到具体代码行
bt 信息不够详细，比如显示为 ，说明程序没有调试符号，编译时加上 -g 选项，然后用 list 命令查看源码：
(gdb) frame 0 (gdb) list
或者使用 info registers 查看寄存器值，结合反汇编 disassemble 分析，在大多数 Linux 服务器 运维 案例中，只要程序编译时带 -g，通过 bt 就能定位到 90% 的 SIGSEGV 问题。
附加到正在运行的进程
如果程序还没崩溃，但你想捕捉即将发生的 SIGSEGV，可以用 GDB 附加：
gdb -p [pid]
然后设置信号断点：
(gdb) handle SIGSEGV stop (gdb) continue
程序收到 SIGSEGV 时会停在 GDB 里，让你看到当时的上下文，这种方法在调试多线程程序时特别有用,但需要注意生产环境建议先复制进程。
预防 linux sigsegv 的编码规范
与其每次都等崩溃再调试，不如从源头减少段错误,至少以下几条习惯能避免大部分问题。
初始化指针并检查返回值
每次声明指针时都赋值为 NULL，malloc 或 new 后立即检查是否为 NULL,很多线上段错误都源于内存分配失败后直接使用指针。
char buf = (char )malloc(1024);
if (!buf) {
// 处理错误，不要继续
}
使用静态分析工具
在代码提交前用 Valgrind 或 AddressSanitizer 运行一遍，Valgrind 可以检测未初始化内存、越界访问和内存泄漏，AddressSanitizer（ASan）是编译器内置工具，性能开销比 Valgrind 小，适合集成到 CI 流程中。
gcc -fsanitize=address -g program.c -o program ./program
ASan 会在检测到非法内存访问时立即打印详细地址和堆栈，比 core dump 还直观。
避免裸指针，使用智能指针
C++ 程序员应优先使用 std::unique_ptr 和 std::shared_ptr，它们能自动管理生命周期，避免悬空指针，在 C 语言中，用显式的所有权约定，比如函数注释中说明“调用者负责释放”。
启用编译器和运行时检测
GCC 和 Clang 有多个选项可以辅助检测内存问题：-Wall -Wextra 开启常见警告，-fstack-protector-strong 检测栈溢出，-D_FORTIFY_SOURCE=2 为某些函数（如 sprintf、strcpy）添加边界检查，这些措施在 Linux 嵌入式 开发环境中尤其重要，因为硬件资源有限,错误更难排查。
生产环境中的 SIGSEGV 排查思路
程序打包部署到服务器后，崩溃日志可能不完整,你需要一套系统化的排查流程。
确认操作系统和内核版本
不同 Linux 发行版对 SIGSEGV 的处理细节略有差异，CentOS 7 默认不写 core dump，而 Ubuntu 20.04 会在 Apport 中记录，用 uname -a 确认内核版本，用 cat /proc/sys/kernel/core_pattern 查看 core 存放路径。
收集系统日志
SIGSEGV 发生时，内核会在 dmesg 中留下记录：
dmesg | tail -20
你会看到类似 segfault at 0x12345678 ip 0xabcdef12 sp 0x00007fff 的信息，这里的 ip 是指令寄存器地址，可以结合 objdump -d 反汇编程序,找到对应函数。
监控和告警
在 Linux 云服务器 上，建议用 systemd 的 ExecStopPost 或自定义脚本捕获程序退出码，如果进程因为 SIGSEGV 退出，退出码是 139（128+11），在监控工具中设置告警规则，当退出码为 139 时立刻通知运维人员，同时保留 core 文件。
区分 SIGSEGV 和 SIGABRT
SIGABRT 通常由 abort() 主动调用产生，assert 失败或 new 抛出异常，而 SIGSEGV 是被动发生的，如果日志中看到 abort，先检查逻辑异常处理；如果是 segfault,则优先考虑内存操作。
常见问题：linux sigsegv 如何处理
Q: linux sigsegv 信号可以忽略吗？
不建议完全忽略，SIGSEGV 的默认动作是终止进程并生成 core dump，如果你用 signal(SIGSEGV, SIG_IGN) 忽略它，程序收到 SIGSEGV 后行为未定义，可能继续运行在错误状态，导致数据损坏或安全漏洞，如果你确实需要自定义处理，只能设置信号处理函数，在其中打印日志后主动退出,绝对不能尝试恢复执行。
Q: 为什么在 Linux 服务器上运行 Java 程序偶尔也会出现 SIGSEGV？
JVM 自身是用 C++ 实现的，当 JVM 内部出现内存错误（JIT 编译的代码有 bug，或者 JVM 堆内存被外部工具破坏），就会收到 SIGSEGV，JVM 通常会生成一个 hs_err_pid.log 文件，包含崩溃时的线程栈、寄存器信息和内存映射，如果你看到这样的日志，可以检查 Java 版本是否过期，或者是否使用了不兼容的 native 库。
Q: 在 Linux 嵌入式开发环境下，没有 GDB 和 core dump 该如何调试？
嵌入式平台资源有限，可以先在编译时开启 -g 并保留符号，然后用 strace 跟踪系统调用，看崩溃前最后几个系统调用是什么，或者使用 printf 二分法缩小范围，在怀疑的函数前后打印日志，另一种方法是利用硬件调试器（如 JTAG）直接读取内存和寄存器，但成本较高，对于大多数嵌入式 Linux 设备，开启 ulimit -c unlimited 并将 core 文件重定向到 TFTP 或 NFS 目录,是更实用的选择。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/512181.html
