SIGABRT（信号6）是程序主动发起的中止请求，主要由assert断言失败或abort()调用触发，导致进程终止并生成core dump；虽可捕获但不应忽略或恢复执行，调试应聚焦定位断言失败根源。
SIGABRT（信号编号 6）不是由硬件异常触发的“被动错误”，而是程序**主动发起的中止请求**，断言失败（assert()）正是它最典型的触发路径之一。
断言失败如何导致SIGABRT
当代码中使用 assert(condition)，且 condition 为假时，glibc 的 __assert_fail() 函数会被调用，其内部直接执行 abort()。而 abort() 的标准行为就是：向当前进程发送 SIGABRT 信号。
- 这个过程是同步、确定的，不依赖外部干扰
- 即使你没显式写
abort()，只要用了未被禁用的assert，失败就等于发 SIGABRT - 编译时加
-DNDEBUG可完全移除所有assert宏，避免此类崩溃
SIGABRT 的默认处理行为
进程收到 SIGABRT 后，若未自定义信号处理函数，将执行系统默认动作：终止进程 + 生成 core dump（如果系统允许且配置开启）。
- 所有打开的文件描述符被关闭，标准 I/O 流被 flush
- 不会像 SIGSEGV 那样留下“内存访问非法”的模糊线索，而是明确告诉你：“程序自己判定不可继续”
- 调试时用
gdb ./a.out core查看堆栈，通常能直接定位到__assert_fail调用点，再往上一层就是你的assert语句所在行
能不能捕获并忽略 SIGABRT？
技术上可以注册 signal(SIGABRT, handler) 或用 sigaction 捕获，但强烈不建议在生产环境中这么做。
- 捕获后返回，程序状态已不可靠（比如堆损坏、锁未释放、对象析构中断）
- POSIX 明确指出：对 SIGABRT 的自定义处理仅适用于“记录日志+快速退出”，不应尝试恢复执行
- Qt 等框架在未捕获 C++ 异常时也会发 SIGABRT，此时捕获反而掩盖了真正的异常源头
排查断言类 SIGABRT 的实用方法
重点不在“怎么拦住它”，而在“为什么它会来”。核心思路是让失败现场更透明：
- 启用 core dump：
ulimit -c unlimited，崩溃后用gdb加载分析调用栈 - 编译加调试信息：
gcc -g -O0，确保符号完整 - 配合 AddressSanitizer：
gcc -fsanitize=address，提前发现内存越界、UAF 等根本诱因 - 检查 assert 条件是否依赖未初始化变量、竞态结果或外部不可靠输入
