统信UOS中“核心转储”提示但无core文件或GDB无法调试，主因是core_pattern路径不可写（需sudo mkdir -p /var/crash && chmod 1777）、ulimit -c为0、setuid程序未启用suid_dumpable=2，或配置未持久化。
统信UOS系统中程序崩溃后提示“核心转储”但找不到core文件，或GDB无法加载调试信息，说明内核转储功能未正确启用——这通常因core_pattern路径不可写、ulimit限制为0、setuid程序被拦截或配置未持久化导致。
设置core文件生成路径与命名规则
系统默认常将core_pattern设为none或指向无权限目录，必须显式指定可写路径并启用PID后缀，否则多进程崩溃会覆盖同一文件。
执行cat /proc/sys/kernel/core_pattern查看当前值，若输出为none或为空，则转储功能实际被禁用。
运行sudo sysctl -w kernel.core_pattern=/var/crash/core.%e.%p.%t将路径设为/var/crash/，其中%e为程序名、%p为进程号、%t为时间戳，确保每个core文件唯一。
创建该目录并赋权：sudo mkdir -p /var/crash && sudo chmod 1777 /var/crash。【chmod 1777是关键，仅此权限才能让所有用户写入但不互相删除】
启用PID后缀避免同名覆盖：sudo sysctl -w kernel.core_uses_pid=1。
解除shell级core大小限制
即使内核配置正确，ulimit -c为0也会直接拦截core文件写入，这是最常被忽略的环节。
运行ulimit -c检查当前限制，若返回0，说明该会话禁止生成任何core文件。
临时解除：执行ulimit -c unlimited，仅对当前终端生效。
永久生效需编辑/etc/security/limits.conf，在文件末尾添加两行：* soft core unlimited* hard core unlimited
修改后必须重新登录用户会话，新配置才会载入。
启用setuid程序的core dump支持
以sudo、su等权限提升方式运行的程序，默认被内核阻止生成core文件，调试root权限崩溃时必须开启此项。
方法一：临时启用
执行echo 2 | sudo tee /proc/sys/fs/suid_dumpable，立即生效，但重启后失效。
方法二：永久生效
向/etc/sysctl.conf追加一行：fs.suid_dumpable = 2，再运行sudo sysctl -p加载。
【不执行此步，sudo ./crash_test类程序崩溃后永远无core文件】
验证core dump是否真实触发
第一步：编写测试程序segv.c：
int main() { char *p = NULL; return *p; }
第二步：编译带调试信息：gcc -g -o segv segv.c。
第三步：运行触发段错误：./segv，终端应显示Segmentation fault (core dumped)。
第四步：检查core文件是否生成：ls -l /var/crash/core.*，若无结果，说明路径不可写、SELinux拦截或磁盘满。
