Linux下触发SIGABRT未生成core dump问题排查咨询

核心结论 #

Linux下触发SIGABRT后，内核负责完成core dump的写入流程，不需要程序额外维持存活时间。你的问题大概率出在信号处理逻辑被覆盖、进程权限/限制异常，或是静态库的特殊处理上，以下是具体排查步骤：

• 检查静态库是否重载了SIGABRT信号处理函数
  静态库可能注册了自定义的SIGABRT处理函数（比如直接调用exit()终止程序），绕过了内核生成core dump的默认流程。可以在raise(SIGABRT)前强制恢复默认信号处理：

  // 在触发SIGABRT前添加
  signal(SIGABRT, SIG_DFL); // 恢复默认处理逻辑
  raise(SIGABRT);
  

• 确认进程级的core dump限制是否生效
  全局ulimit设置为unlimited不代表进程实际生效——如果程序通过sudo、启动脚本或服务管理工具启动，限制可能被重置。可以在程序中打印当前限制：

  #include <sys/resource.h>
  #include <stdio.h>
  
  // 在程序启动或出错位置前添加
  struct rlimit rlim;
  getrlimit(RLIMIT_CORE, &rlim);
  printf("当前Core Dump限制: 软限制=%lld, 硬限制=%lld\n", 
         (long long)rlim.rlim_cur, (long long)rlim.rlim_max);
  

  如果软限制不是RLIM_INFINITY，需要在启动程序前显式设置：ulimit -c unlimited && ./your_program

• 检查core dump的生成路径与权限
  默认core dump生成在程序当前工作目录，需确保进程对该目录有写入权限。可以查看系统core dump路径配置：

  cat /proc/sys/kernel/core_pattern
  

  如果配置的是管道（比如|/usr/lib/systemd/systemd-coredump）或自定义路径，要确认路径存在、权限足够。临时修改为当前目录生成：

  sudo echo "./core.%p" > /proc/sys/kernel/core_pattern
  

  （%p会替换为进程ID，方便区分不同进程的core文件）

• 排查线程上下文的异常
  非主线程触发SIGABRT默认也会生成core dump，但如果线程是分离状态（PTHREAD_CREATE_DETACHED），或触发信号后被其他线程强制终止，可能影响core dump生成。可以在触发前打印线程ID：

  #include <pthread.h>
  #include <stdio.h>
  
  // 在raise前添加
  printf("触发信号的线程ID: %lu\n", (unsigned long)pthread_self());
  

  同时检查代码中是否有其他线程调用pthread_cancel或类似函数终止该线程的逻辑。

内容的提问来源于stack exchange，提问作者confused