core dumped 意味着程序在运行时因严重错误而崩溃，系统会将程序崩溃时的内存状态保存到一个 core 文件中，这个文件可以用来分析程序崩溃的原因。以下是分析 core dumped 文件的详细步骤：
1. 确认 core 文件是否生成及位置
- 检查
core文件生成是否开启：默认情况下，系统可能未开启core文件生成。可以通过ulimit -c命令查看当前core文件大小限制，如果输出为0，则表示未开启。可以使用ulimit -c unlimited临时开启（仅对当前会话有效），若要永久开启，需要修改/etc/security/limits.conf文件。 - 查找
core文件位置：core文件通常位于程序崩溃的当前目录下，命名为core或core.<进程 ID>。也可以通过修改/proc/sys/kernel/core_pattern文件来指定core文件的保存路径和命名规则。
2. 使用 gdb 进行调试分析
gdb（GNU Debugger）是一个强大的调试工具，可以用来分析 core 文件。假设程序名为 your_program，core 文件名为 core，可以按照以下步骤进行分析：
启动 gdb 并加载程序和 core 文件
gdb your_program core
此命令会启动 gdb 并加载程序的可执行文件和 core 文件。
查看程序崩溃时的堆栈信息
在 gdb 提示符下，输入 bt（backtrace）命令查看程序崩溃时的函数调用堆栈，它能显示程序崩溃时执行到了哪个函数以及函数调用的顺序。
(gdb) bt
查看变量的值
若要查看某个变量在崩溃时的值，可以使用 p（print）命令。例如，要查看变量 x 的值：
(gdb) p x
查看程序崩溃时的源代码位置
使用 l（list）命令查看程序崩溃时所在的源代码位置。
(gdb) l
3. 示例分析
假设存在一个简单的 C 程序 test.c，内容如下：
#include <stdio.h>
int main() {
int *ptr = NULL;
*ptr = 10; // 这里会导致段错误
return 0;
}
编译并运行该程序：
gcc -g -o test test.c
./test
程序会崩溃并生成 core 文件（前提是 core 文件生成已开启）。然后使用 gdb 分析：
gdb test core
在 gdb 中输入 bt 命令，会显示类似如下的堆栈信息：
(gdb) bt
#0 0x00005555555546d7 in main () at test.c:5
这表明程序在 test.c 文件的第 5 行崩溃，原因是对空指针进行了解引用操作。
通过以上步骤，你可以利用 core 文件分析程序崩溃的原因。如果程序是多线程的，分析可能会更复杂，需要使用 gdb 的多线程调试功能。