核心转储分析需先确认core文件是否生成（检查ulimit -c和core_pattern），再通过GDB回溯调用栈定位崩溃点，结合strace、journalctl等工具识别信号来源与运行上下文，综合排查代码缺陷或环境异常。

排查进程收到核心转储信号（如 SIGSEGV、SIGABRT、SIGFPE 等）的原因，关键在于确认“谁发的信号”“为什么发”以及“程序当时在做什么”。这不是单看日志就能解决的问题，而要结合系统配置、运行上下文和崩溃现场综合判断。

确认是否真生成了 core 文件

没有 core 文件，就无法做后续分析。先验证系统是否允许生成：

• 运行 ulimit -c，若输出为 0，说明被禁用；需临时启用：ulimit -c unlimited
• 检查 /proc/sys/kernel/core_pattern，确认 core 文件写入路径是否可写、磁盘是否有空间
• 注意：有些系统（尤其是容器或云服务器）默认关闭 core dump，或重定向到 systemd-coredump，此时需查 coredumpctl list 或 journalctl -t systemd-coredump

识别触发 core dump 的具体信号

常见信号包括 SIGSEGV（段错误）、SIGABRT（主动中止）、SIGFPE（浮点异常）、SIGBUS（总线错误）等。可通过以下方式定位：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 查看终端或日志中原始报错，例如：Segmentation fault (core dumped) → 基本对应 SIGSEGV
• 用 strace -e trace=signal ./your_program 运行程序，实时捕获信号收发过程
• 若程序由 systemd 启动，启用 StandardOutput=journal+console 并配合 journalctl -u your-service --since "1 hour ago" 查看完整上下文

用 GDB 分析 core 文件定位根源

有了 core 文件和带调试信息的可执行文件（编译时加 -g），就能回溯崩溃现场：

• 运行 gdb ./program core.xxx，进入调试器后输入 bt（backtrace）查看函数调用栈
• 用 info registers 查看寄存器状态，确认 PC（程序计数器）指向哪一行代码
• 用 frame N 切换到某一层栈帧，再用 list 或 print variable 检查变量值和上下文
• 特别关注栈顶帧中的指针解引用、数组越界、空指针访问、use-after-free 等典型模式

检查程序自身行为与环境因素

有些 core dump 不是代码缺陷，而是运行时环境异常触发：

• 内存不足时，OOM Killer 可能向进程发送 SIGKILL（不会生成 core，但日志里有 “Out of memory”）
• SELinux/AppArmor 策略拒绝操作，可能静默终止并生成 core（查 ausearch -m avc -ts recent）
• LD_PRELOAD 加载了不兼容的共享库，或 malloc hook 导致堆损坏
• 多线程环境下未加锁访问全局变量、竞态条件引发非法内存访问