c++ core dump配置 c++ linux下如何开启和分析core dump文件-C++-PHP中文网

core dump未生成需先检查ulimit -c是否为0、/proc/sys/kernel/core_pattern配置及权限；gdb调试需确保core与原二进制匹配且含调试符号，动态库路径正确。

c++ core dump配置 c++ linux下如何开启和分析core dump文件

Linux 默认可能禁用 core dump，即使程序崩溃也不会留文件。最常见原因是 ulimit -c 被设为 0。

运行 ulimit -c 查当前限制：输出 0 表示关闭，unlimited 或具体数字（如 1048576）才可能生成
临时开启：执行 ulimit -c unlimited（仅对当前 shell 及其子进程生效）
永久生效需改配置：在 /etc/security/limits.conf 加一行 * soft core unlimited，或在 systemd 服务中设 LimitCORE=infinity
别漏掉内核参数：/proc/sys/kernel/core_pattern 决定 core 文件名和位置，默认是 core，但若被改成 |/usr/lib/systemd/systemd-coredump（常见于 systemd 发行版），则 core 不落地为文件，而是走 coredumpctl —— 这时得用 coredumpctl dump 提取

就算有 core.xxx，gdb ./myapp core.xxx 报错“not in executable format”或找不到符号，大概率是二进制变了或没调试信息。

确保 gdb 加载的是**崩溃时运行的那个 exact 二进制**：重编译过、strip 过、甚至只是 relink 了，都可能导致栈帧无法解析
编译时必须带 -g（推荐 -g -O0 开发期；上线可保留 -g 但开优化，只要不 strip）
如果用 strip ./myapp 清除了符号，gdb 就只剩地址，看不到函数名和变量 —— 即便有 core 也基本没法查
验证是否匹配：用 file ./myapp 和 file core.xxx 看架构一致；再用 readelf -n ./myapp | grep 'NT_PRSTATUS' 确认它确实含核心寄存器信息

很多同学搜不到 core 文件，不是没生成，是写到别的地方去了，或者被管道吞掉了。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

查真实路径：cat /proc/sys/kernel/core_pattern
如果输出是 core 或 core.%e.%p 这类纯文件名，core 会生成在**进程当前工作目录**（不是源码目录，也不是 home，是 chdir() 后的位置，常是 / 或 /tmp）
如果含 /（如 /var/crash/core.%e.%p），要确认该路径存在且进程有写权限（尤其 daemon 常以 nobody 运行）
如果以 | 开头（如 |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h），core 不落地，systemd 会接管并存进二进制格式 —— 此时用 coredumpctl list 查记录，coredumpctl dump -o mycore ./myapp 导出原始 core 文件

能打开 core，但 bt 显示一堆 ??，说明符号缺失或动态库没加载上。

先 info sharedlibrary：看 gdb 是否识别到所有 so，状态列显示 Yes 才表示符号已读入；若为 No，说明路径不对或文件缺失
so 路径必须和崩溃时一致：用 ldd ./myapp 记下依赖路径，再在 gdb 里用 set solib-search-path /path/to/libs 或 set sysroot /（若跨环境调试）
如果 so 是 dlopen 加载的，且没带 RTLD_GLOBAL，gdb 可能无法自动关联符号 —— 此时手动 add-symbol-file /path/to/libxxx.so 0x7ffff7bc0000（地址从 info proc mappings 里找）
避免 strip system 库：strip --strip-unneeded /lib/x86_64-linux-gnu/libc.so.6 会导致所有基于它的 core 都丢 libc 符号，bt 一跳就断