统信uos中出现“core dumped”表明程序因段错误等严重异常终止并生成core文件用于调试，但需手动验证配置（ulimit、core_pattern、suid_dumpable）、搜索文件、用gdb+bt定位崩溃行，并结合journalctl/dmesg排查oom等系统级原因。
当程序在统信UOS中运行突然退出并显示“核心转储”（Core dumped），说明已发生严重错误（如段错误、非法内存访问），系统按配置生成了core文件用于事后分析，但默认不自动打开调试器，需手动介入定位代码缺陷。
确认core文件是否真正生成
很多用户以为提示出现就一定有文件，其实常因权限、路径或ulimit限制导致静默失败。
执行 ulimit -c 查看当前会话core大小限制，若输出为 0，则根本不会写入任何文件。
运行 sudo find / -name "core.*" -type f 2>/dev/null | head -n 5 搜索全盘可能的core文件，重点检查程序所在目录、/var/lib/systemd/coredump/ 和你自定义的 /var/crash/ 路径——若无结果，说明配置未生效或程序被SELinux拦截。
执行 cat /proc/sys/kernel/core_pattern，若返回 none 或为空，必须先设置有效路径，否则后续所有分析都无从谈起。
用GDB加载core文件定位崩溃点
这是最直接有效的定位方式，前提是程序编译时带 -g 调试信息，且core文件真实存在。
假设你的可执行文件叫 myapp，在当前目录找到 core.12345，运行：gdb ./myapp core.12345
进入GDB后立即输入 bt（backtrace），它会打印出函数调用栈，最上面一行就是崩溃发生的源码位置，例如：#0 0x00005555555551a2 in parse_config (path=0x0) at config.c:47
这表示程序在 config.c 文件第47行，对空指针 path 做了非法解引用。
若 bt 显示的是问号或地址而非源码行，说明缺少调试符号——此时需重新用 gcc -g 编译，或安装对应软件包的 -dbg 版本。
验证并启用setuid程序的core dump支持
如果你运行的是 sudo ./crash_test 或其他以root权限启动的程序，即使其他配置全对，默认也不会生成core文件。
方法一：临时启用
执行 echo 2 | sudo tee /proc/sys/fs/suid_dumpable，该命令将允许setuid程序崩溃时写入core。
方法二：永久生效
向 /etc/sysctl.conf 追加一行：fs.suid_dumpable = 2
然后运行 sudo sysctl -p 加载。不执行这一步，sudo运行的程序崩溃后永远看不到core文件。
注意：此操作需root权限，且修改后仅对新启动的进程生效，已运行的sudo进程不受影响。
用valgrind检测运行时内存问题
当GDB只能看到崩溃瞬间、却找不到根源时，valgrind能帮你提前捕获非法行为。
安装工具：sudo apt install valgrind
运行检测：valgrind --leak-check=full --show-leak-kinds=all ./myapp
它会逐行报告：无效读写、使用未初始化内存、内存泄漏、越界访问等。比如输出 Invalid read of size 4 at 0x...: process_data (logic.c:89)，比等到段错误再回溯更高效。
valgrind无法替代GDB，但它能在程序尚未崩溃前暴露隐患，尤其适合排查偶发性、条件触发的内存错误。
检查系统日志确认崩溃上下文
core dump只是结果，日志里常藏着诱因——比如OOM killer主动杀死进程，或磁盘满导致写core失败。
第一步：查本次启动的错误事件sudo journalctl -b -p 3（-p 3 表示error级别）
第二步：聚焦与崩溃时间接近的记录
先用 date 看当前时间，再执行：sudo journalctl -b --since "2 minutes ago" | grep -i "segfault\|kill\|oom\|core"
第三步：检查内核是否因资源不足终止进程dmesg -T | grep -i "killed process"，若出现类似 Killed process 12345 (myapp) total-vm:2048000kB, anon-rss:1567892kB, file-rss:0kB, shmem-rss:0kB，说明是内存耗尽被OOM killer干掉，和代码bug无关，应优化内存使用或增加swap。
