<p>默认禁用core dump，需先执行ulimit -c unlimited临时开启或在/etc/security/limits.conf中添加“* soft core unlimited”永久启用；再通过/proc/sys/kernel/core_pattern配置路径与命名规则。</p>
Linux下如何开启core dump生成
默认情况下，大多数Linux发行版会禁用core dump，所以程序崩溃时根本不会生成core文件。关键不是“怎么读”，而是“先得让它写出来”。
检查当前限制：
$ ulimit -c
输出0就说明被禁用了。临时开启（当前shell及子进程有效）：
$ ulimit -c unlimited
若需永久生效，需修改系统配置：
立即学习“C++免费学习笔记（深入）”；
-
/etc/security/limits.conf中添加：* soft core unlimited - 确保
PAM加载了 limits 模块（检查/etc/pam.d/common-session是否含pam_limits.so） - 注意：systemd服务默认忽略
ulimit，需在service文件中显式设置：LimitCORE=infinity
core文件名和存放路径怎么控制
Linux用/proc/sys/kernel/core_pattern决定core文件名与位置，它支持格式化变量（如%e表示可执行名，%p表示PID）。
常见配置方式：
- 直接写路径：
echo "/var/crash/core.%e.%p" > /proc/sys/kernel/core_pattern（需root） - 用
systemd-coredump接管（推荐）：echo "|/usr/lib/systemd/systemd-coredump %E %p %u %g %s %t %c %h" > /proc/sys/kernel/core_pattern，此时core不落地为文件，而由systemd按策略存档 - 注意：
core_pattern开头是|则走管道，否则当路径；路径必须有写权限，且所在分区不能满
用gdb读取core dump定位崩溃点
有了core文件后，用gdb加载符号信息是关键——没有调试信息，gdb只能看到汇编，几乎无法分析。
确认你的二进制含调试符号（编译时加-g），再执行：
$ gdb ./my_program core.my_program.12345
进入gdb后常用操作：
-
bt（backtrace）：看崩溃时的调用栈 -
info registers：查寄存器状态，尤其rip/rsp是否异常 -
list或frame 0后list：定位到源码行（依赖调试符号和源码路径） - 如果提示
No symbol table is loaded，说明二进制被strip过或未编译带-g
常见失败原因和绕过技巧
即使开了ulimit，仍没core？优先排查这几个硬性条件：
- 进程有
setuid/setgid权限（如root启动的普通用户程序），内核默认禁止dump——需设/proc/sys/fs/suid_dumpable = 2 - 程序自己调用了
prctl(PR_SET_DUMPABLE, 0)，主动放弃dump能力 - 磁盘配额（quota）或inode耗尽，导致写入失败（
dmesg里搜coredump常能看到Cannot allocate memory这类误导信息） - 用
systemd-coredump时，coredumpctl list可查历史记录，coredumpctl debug my_program直接进gdb，比手动找文件更可靠
真正麻烦的不是生成或读取，而是符号缺失、路径变动、权限链断裂——这些细节不提前验证，等线上出问题再补救，基本来不及。
