Linux默认不生成core文件需逐层解除限制：先用ulimit -c unlimited开启进程级权限，再配置kernel.core_pattern指定有效路径与命名规则，确保目录权限为1777，对setuid程序还需设置kernel.suid_dumpable=2，并验证磁盘空间、SELinux及systemd服务LimitCORE等。
Linux 默认不生成 core 文件，不是系统坏了，而是它被层层关掉了——ulimit -c 设为 0、/proc/sys/kernel/core_pattern 指向无效路径、目录权限不对、systemd 服务没配 LimitCORE，甚至 setuid 程序还被 kernel.suid_dumpable 拦着。得一层层打开，缺一不可。
检查并解除 ulimit -c 限制
这是第一道关卡，也是最容易忽略的：即使内核允许 dump，进程自己没权限写也不行。
-
ulimit -c输出 0 表示禁用；输出unlimited或具体数字（单位是 512 字节块）才表示可用 - 临时生效：在目标终端中运行
ulimit -c unlimited；但只对当前 shell 及其直接子进程有效 - 永久生效：加到用户级配置（如
~/.bashrc）或系统级配置（/etc/security/limits.conf中写* soft core unlimited和* hard core unlimited），注意后者需重新登录 - 关键点：systemd 服务完全不继承 shell 的 ulimit，必须单独在 unit 文件里加
LimitCORE=infinity
配置 /proc/sys/kernel/core_pattern 路径与命名
core 文件往哪写、叫什么名，全由这个内核参数决定——它不看当前目录有没有写权限，只认你写的路径是否存在、父目录权限是否为 1777。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查看当前设置：
cat /proc/sys/kernel/core_pattern；默认可能是core，意味着只写在进程工作目录，极易被覆盖或找不到 - 临时改写到
/tmp/core.%e.%p.%t：echo '/tmp/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern - 必须提前建好目录并设权限：
sudo mkdir -p /tmp/coredumps && sudo chmod 1777 /tmp/coredumps；777不够，必须是1777（sticky bit），否则内核拒绝写入 - 永久生效：写入
/etc/sysctl.conf，如kernel.core_pattern=/var/crash/core.%e.%p.%t，再执行sudo sysctl -p - 若值以
|开头（如|/usr/lib/systemd/systemd-coredump），说明走用户态处理器，要确认systemd-coredump服务已启用且运行正常
绕过 suid_dumpable 和 core_uses_pid 的隐形拦截
普通程序可能 dump 成功，但 sudo、passwd 这类 setuid 程序却静默失败——问题常出在这两个内核开关上。
-
kernel.suid_dumpable默认是 0（禁止 dump），导致 setuid 程序崩溃时连文件都不生成；临时开启：echo 2 | sudo tee /proc/sys/kernel/suid_dumpable（2 表示按进程 dumpable 标志决定） -
kernel.core_uses_pid控制是否在文件名里加 PID；设为 1 可避免多进程崩溃时文件被覆盖：echo 1 | sudo tee /proc/sys/kernel/core_uses_pid - 这两个参数修改后不会自动持久化，需写进
/etc/sysctl.conf并sysctl -p - 某些发行版（如 RHEL 8+/Alibaba Cloud Linux 3）默认锁死
suid_dumpable=0，不手动改就永远看不到特权程序的 core
验证 core 是否真能落地，别信“Segmentation fault (core dumped)”提示
终端打出那行字，不代表文件生成了——它只是内核尝试写入后的乐观反馈。实际可能因磁盘满、目录不可写、SELinux 拦截、或 core_pipe_limit 太小而失败。
- 写个崩溃测试程序：
sleep 1; kill -SEGV $$，然后立刻查目标目录有没有新 core 文件 - 用
readelf -l core | grep LOAD对比原 binary 的段数量，确认 core 是否完整（缺段常见于启用了VM_DONTDUMP的程序） - 检查磁盘空间：
df -h /tmp或你配置的路径所在分区；ls -lh /tmp/core*看文件大小是否合理（空或几 KB 往往是失败） - 查内核日志：
dmesg | tail -20，留意 “failed to write core”、“permission denied” 或 “No space left on device” 类报错 - 容器环境要额外注意：宿主机配置不影响容器内进程，得在容器启动时挂载
/proc/sys或用--ulimit core=-1:-1
最常卡住的地方不是某一个配置项没开，而是多个环节叠加失效：比如你在 shell 里 ulimit -c unlimited 了，但跑的是 systemd 服务，又没加 LimitCORE；或者 core_pattern 指向 /var/crash，但忘了 chmod 1777 /var/crash。每一步都得独立验证，不能靠“应该可以”。
