ulimit -c 是核心开关，不设它后续配置全无效；系统默认为0即禁用，必须设为unlimited或具体数值才能生成core文件，且需配合core_pattern路径可写、权限正确等条件。
ulimit -c 是核心开关，不设它，后面全白搭
系统默认禁用 core 文件生成，ulimit -c 返回 0 就代表关着。必须先打开这个开关，否则无论 /proc/sys/kernel/core_pattern 怎么配，都不会有 core 文件落地。
- 临时生效（当前终端有效）：
ulimit -c unlimited或指定大小如ulimit -c 104857600（100MB） - 永久生效推荐改
/etc/security/limits.conf，加一行：* hard core unlimited—— 注意是hard，soft可能被运行时覆盖 - 改完
limits.conf需要新登录会话才生效，SSH 重连或切用户验证；source ~/.bashrc对 ulimit 的 hard limit 无效 - 容器环境（如 Docker）需额外传参：
--ulimit core=-1，否则宿主机的 limits 不透传
core_pattern 决定文件存哪、叫什么
/proc/sys/kernel/core_pattern 是路径和命名规则的总开关。不配它，core 文件默认落在程序启动目录，容易找不到、被覆盖、权限拒绝。
- 快速测试用：
echo "/tmp/core-%e-%p-%t" | sudo tee /proc/sys/kernel/core_pattern - 关键参数：
%e（程序名）、%p（PID）、%t（时间戳），避免重名和混淆 - 目标目录（如
/tmp/core_dumps/）必须存在且进程有写权限：sudo mkdir -p /tmp/core_dumps && sudo chmod 777 /tmp/core_dumps - 生产环境慎用
777，但调试阶段比“没日志”强得多；若用 systemd coredump，路径由systemd-coredump管理，不走这个接口
常见失败原因：权限、路径、信号拦截三连击
即使 ulimit -c 和 core_pattern 都设了，仍看不到 core 文件，大概率卡在这几个点：
-
/proc/sys/kernel/core_pattern指向的目录不存在，或进程 UID/GID 无写权限 —— 用ls -ld /your/path看实际权限 - 程序用了
prctl(PR_SET_DUMPABLE, 0)主动禁掉 dump，GDB 也救不了；检查代码或 strace 启动过程 - 崩溃由
SIGKILL（kill -9）触发 —— 它不能被捕获也不能产生 core，换kill -6（SIGABRT）或kill -11（SIGSEGV）测试 - 文件系统挂载时带
noexec或nosuid选项，某些内核版本会拒写 core ——mount | grep $(df . | tail -1 | awk '{print $1}')查看
真正卡住的往往不是 GDB 怎么用，而是 core 根本没生成出来。盯住 ulimit -c 输出、cat /proc/sys/kernel/core_pattern 结果、以及目标目录的 chmod 和 df -h，这三处对不上，GDB 就是巧妇难为无米之炊。
