core文件过大是因记录进程崩溃时全部虚拟内存，尤其堆和共享库映射区；ulimit -c需设为unlimited防截断，core_pattern应指向大容量独立分区，并配合gdb -n等技巧加速调试。
core文件为什么太大
core文件大小基本等于进程崩溃时的虚拟内存占用量，尤其是堆（heap）和共享库映射区域。一个开了几十个线程、加载了大模型或大量动态库的进程，core可能轻松上GB。这不是异常，而是内核忠实记录现场的结果。
ulimit -c 设置不当会直接导致core被截断
如果用 ulimit -c 1024 这类带数值的限制，而实际崩溃需要 2GB 内存快照，系统只会写入前 1024KB，生成一个不完整 core。此时用 gdb 加载会立刻报错："Core file truncated: cannot read register state" 或类似提示，根本无法回溯调用栈。
-
ulimit -c unlimited是安全底线，必须先确认执行成功（再跑一次ulimit -c看输出是不是unlimited） - 仅在当前 shell 有效；若要永久生效，得改
/etc/security/limits.conf（加* hard core unlimited）或用户级~/.bashrc - 容器环境里，
ulimit需在启动容器时通过--ulimit core=-1:-1显式传递，否则宿主机设置无效
用 core_pattern 控制生成位置，避免填满根分区
默认 core 写在当前工作目录，但很多服务以 root 启动、工作目录是 / 或 /var/run，一旦 core 过大极易触发磁盘满，连 ssh 都登不上。更稳妥的做法是定向到独立大容量分区：
- 检查当前策略：
cat /proc/sys/kernel/core_pattern，常见值如core（默认）、core.%p、或已配置的路径 - 临时重定向（需 root）：
echo "/data/core/core-%e-%p-%t" > /proc/sys/kernel/core_pattern，其中%e是程序名，%p是 pid，%t是时间戳，避免覆盖 - 确保
/data/core目录存在、有写权限、且所在分区空间充足（建议预留 ≥2× 最大预期 core 大小） - 注意：修改
core_pattern不影响ulimit限制，两者必须同时配好
调试时跳过无关内存区域加快加载
gdb 加载超大 core 很慢，主要卡在读取整个内存镜像。实际调试往往只关心栈帧、寄存器和崩溃点附近变量，不需要全量加载：
- 启动时加
-n参数跳过符号读取加速：gdb -n ./myapp core.12345，进 gdb 后再用file ./myapp手动加载符号 - 用
set max-value-size 1024限制变量打印长度，防 gdb 卡死 - 优先执行
bt（backtrace），它依赖栈内存，通常能快速定位崩溃函数；若bt失败，大概率是 core 被截断或路径不对 - 真要查堆内容时，再用
info proc mappings看哪些内存段被完整保存，针对性x/10xw查看
真正麻烦的不是 core 太大，而是它生成后没人知道去哪儿了——core_pattern 配错、ulimit 没生效、或目录权限不足，都会让 core “静默消失”。每次部署新服务前，务必用最小段错误程序验证整套流程是否走通。
