Linux Core Dump 测试操作手册

前言

本文档专为测试小白编写，用于指导 Linux 环境下 C++ SDK 程序测试过程中，Core Dump（以下简称 Core）文件的设置、获取、解析及 Bug 提交全流程，同时详细说明主流 Core 解析工具的使用方法、区别与共性，帮助测试人员快速定位程序崩溃问题，高效完成测试反馈。

核心目标：让测试人员掌握 Core 相关基础操作，无需深度调试能力，即可完成"崩溃复现→Core 获取→解析堆栈→提交 Bug"的全流程操作。

第一章 基础概念

1.1 什么是 Core 文件

Core 文件（Core Dump）是 Linux 系统下，C/C++ 程序因严重错误（如空指针、数组越界等）异常退出时，操作系统生成的"程序崩溃现场快照"，包含崩溃瞬间的内存镜像、寄存器状态、函数调用栈、线程信息等关键数据，是开发定位崩溃原因的核心依据。

简单理解：Core 文件 = 程序崩溃时的"现场记录仪"，没有 Core 仅能确认"程序崩了"，有 Core 可明确"在哪崩、为什么崩"。

1.2 常见 Core 触发原因

• 空指针解引用（最常见，如对 nullptr 赋值、取值）；

• 内存操作异常（数组越界、野指针、重复释放内存、堆破坏）；

• 栈溢出、除零错误、非法指令、权限不足；

• 多线程竞争导致的内存踩踏、死锁（间接触发崩溃）。

1.3 与 Android/iOS App 崩溃的对比

1.3.1 相同点

• 本质都是程序异常崩溃后生成的"问题记录"，用于定位 Bug；

• 核心作用一致：均可获取崩溃位置、函数调用栈、线程信息；

• 常见崩溃原因相同：空指针、内存越界、野指针等。

1.3.2 不同点

对比项

Linux Core 文件

Android/iOS 崩溃日志

载体类型

二进制内存镜像文件

文本日志 + 符号化堆栈

默认开关

默认关闭，需手动开启

默认开启，无需手动设置

保存位置

默认当前工作目录，可自定义路径

系统默认日志目录（如 Android 的 logcat 缓存）

解析工具

gdb、coredumpctl、addr2line 等

Android：logcat、ndk-stack；iOS：atos、Xcode 调试工具

信息完整度

极高，包含完整内存、寄存器、线程状态

中等，主要包含堆栈、线程、错误码，无完整内存镜像

体积大小

较大（几百MB~GB，取决于程序内存占用）

较小（KB~MB，仅文本日志）

适用场景

Linux 下 C/C++ 原生程序、SDK 测试

手机 App（Java/Kotlin/Swift + 原生层）测试

总结：Linux Core 更底层、信息更完整，类似"法医尸检报告"；手机崩溃日志更轻量，类似"门诊病历"。

第二章 Core 文件的设置与获取

2.1 前提说明

测试前需确认 Linux 机器已开启 Core 生成功能，默认情况下系统关闭 Core 生成（避免占用磁盘空间），需手动设置。

2.2 Core 生成设置（必做步骤）

2.2.1 查看当前 Core 生成状态

执行以下命令，查看当前终端是否允许生成 Core：

ulimit -c

结果说明：

• 输出 0：关闭 Core 生成，程序崩溃不会产生 Core 文件；

• 输出 unlimited 或具体数字：允许生成，数字代表 Core 文件最大体积限制（单位：blocks）。

2.2.2 临时开启 Core 生成（当前终端生效）

仅对当前打开的终端有效，关闭终端后失效，适合临时测试：

ulimit -c unlimited

2.2.3 永久开启 Core 生成（重启后生效）

适合长期测试环境，两种方法任选其一：

方法1：修改 /etc/security/limits.conf 文件

编辑配置文件

vim /etc/security/limits.conf

在文件末尾添加以下两行（* 表示所有用户生效）

• soft core unlimited
• hard core unlimited

方法2：修改 /etc/profile 或 ~/.bashrc 文件

编辑全局配置（所有用户生效）

vim /etc/profile

或编辑当前用户配置（仅当前用户生效）

vim ~/.bashrc

在文件末尾添加

ulimit -c unlimited

使配置立即生效

source /etc/profile # 对应全局配置

或 source ~/.bashrc # 对应当前用户配置

2.2.4 自定义 Core 文件名称与保存路径（可选）

默认 Core 文件名为 core，多次崩溃会覆盖原有文件，建议自定义格式，避免覆盖：

设置 Core 文件保存路径和命名格式

echo "/var/coredump/core.%e.%p.%t" > /proc/sys/kernel/core_pattern

格式说明：

• %e：崩溃程序的名称；

• %p：崩溃程序的进程 ID（PID）；

• %t：崩溃发生的时间戳；

• /var/coredump/：Core 文件保存路径（需提前创建，mkdir -p /var/coredump）。

2.3 Core 文件的获取

2.3.1 正常获取流程

1. 按 2.2 节设置好 Core 生成功能；

2. 在终端运行待测试的 C++ SDK 程序（如 ./test_sdk）；

3. 程序崩溃时，终端会提示 段错误 (核心已转储)；

4. 到 Core 保存路径（默认当前目录）找到生成的 Core 文件（如 core、core.test_sdk.12345.1690000000）。

2.3.2 找不到 Core 文件的常见原因

• 未开启 Core 生成（ulimit -c 输出 0）；

• 程序工作目录与当前终端目录不一致（Core 生成在程序工作目录，而非终端所在目录）；

• 保存路径无写入权限（如未创建 /var/coredump 目录，或权限不足）；

• 磁盘空间不足，无法生成 Core 文件；

• 容器、沙箱等测试环境限制了 Core 生成功能。

2.3.3 快速查找 Core 文件

若忘记 Core 保存路径，执行以下命令全局查找：

find / -name "core*" 2>/dev/null

说明：2>/dev/null 用于屏蔽无权限目录的报错，仅显示可访问的 Core 文件。

第三章 Core 文件解析工具详解（重点）

测试人员核心需求：获取崩溃堆栈，定位崩溃位置，无需深度调试。以下介绍 3 种主流解析工具（gdb、coredumpctl、addr2line），重点说明实操方法、区别与共性，均搭配测试场景实例。

3.1.1 前置准备：模拟C++程序崩溃（可直接复制实操）

为方便测试人员实操，先编写2个可直接编译运行、能触发崩溃的C++代码示例（覆盖最常见的崩溃场景），后续所有工具解析均基于这两个示例展开，确保实操连贯性。

示例1：空指针解引用崩溃（最常见场景）

创建文件 test_nullptr.cpp，代码如下（复制到Linux机器即可）：

#include

#include

using namespace std;

// 模拟SDK中的一个函数，触发空指针解引用

void sdk_test_func() {

string* str = nullptr; // 定义空指针

cout << "SDK测试：" << str->c_str() << endl; // 空指针取值，触发崩溃

}

int main() {

cout << "开始运行测试SDK程序（空指针崩溃示例）" << endl;

sdk_test_func(); // 调用崩溃函数

return 0;

}

编译命令（必须带 -g 调试信息，否则无法解析具体代码行）：

g++ -g test_nullptr.cpp -o test_nullptr_sdk

运行程序（触发崩溃）：

ulimit -c unlimited # 确保开启Core生成

./test_nullptr_sdk

运行结果（崩溃提示）：

开始运行测试SDK程序（空指针崩溃示例）

段错误 (核心已转储)

此时当前目录会生成 Core 文件（默认名为 core，若自定义路径则在对应目录）。

示例2：数组越界崩溃（常见场景）

创建文件 test_array.cpp，代码如下：

#include

using namespace std;

// 模拟SDK中数组操作，触发越界

void sdk_array_func() {

int arr[5] = {1,2,3,4,5}; // 数组长度为5，下标0-4

cout << "数组第10个元素：" << arr[9] << endl; // 下标9越界，触发崩溃

}

int main() {

cout << "开始运行测试SDK程序（数组越界崩溃示例）" << endl;

sdk_array_func(); // 调用崩溃函数

return 0;

}

编译命令：

g++ -g test_array.cpp -o test_array_sdk

运行程序（触发崩溃）：

ulimit -c unlimited

./test_array_sdk

运行结果（崩溃提示）：

开始运行测试SDK程序（数组越界崩溃示例）

段错误 (核心已转储)

后续工具解析示例，将分别使用这两个崩溃程序的 Core 文件，确保测试人员可直接复制代码、编译运行、解析验证，全程实操无门槛。

3.1 工具共性说明

• 核心作用一致：均可解析 Core 文件，获取程序崩溃的函数调用栈、崩溃位置；

• 依赖条件一致：需搭配"崩溃程序的可执行文件"（最好是带调试信息 -g 编译的版本），否则无法解析出具体代码行；

• 适用场景一致：均用于 Linux 环境下 C/C++ 程序 Core 文件解析，适配测试人员的基础需求。

3.2 工具详解（含实例）

3.2.1 GDB（GNU Debugger）------ 最常用、功能最全面

作用

Linux 下最主流的调试工具，可直接加载 Core 文件和可执行程序，查看崩溃堆栈、局部变量、线程信息，支持单步调试（测试人员无需掌握），是测试人员解析 Core 的首选工具。

安装方法

CentOS/RHEL 系统

yum install gdb -y

Ubuntu/Debian 系统

apt install gdb -y

实操实例（结合测试场景，基于前置崩溃示例）

前提：已完成前置准备，生成 test_nullptr_sdk 可执行程序（带 -g 调试信息），且运行后生成 Core 文件（默认名为 core）。

1. 加载 Core 文件和可执行程序：

   gdb ./test_nullptr_sdk core执行后进入 gdb 交互界面，提示"Core was generated by `./test_nullptr_sdk'."，表示加载成功（若提示无权限，执行 chmod +x ./test_nullptr_sdk）。

2. 查看崩溃堆栈（测试人员核心操作）：

   bt输出示例：

   #0 0x0000000000401206 in sdk_test_func () at test_nullptr.cpp:9

   #1 0x0000000000401246 in main () at test_nullptr.cpp:14解读：崩溃发生在 sdk_test_func 函数中，对应 test_nullptr.cpp 文件第 9 行（代码：cout << "SDK测试：" << str->c_str() << endl;），明确是空指针解引用导致崩溃；第1行表示该函数由 main 函数第14行调用，完整定位崩溃链路。

3. 常用辅助命令（测试必背，结合示例实操）：

   bt full：打印详细堆栈，包含局部变量值，可查看 str 指针的值（确认为空指针）；

   (gdb) bt full

   #0 0x0000000000401206 in sdk_test_func () at test_nullptr.cpp:9

   str = 0x0 # 明确str是空指针（0x0）

   #1 0x0000000000401246 in main () at test_nullptr.cpp:14

   No locals.

4. f 0：切换到崩溃的最上层堆栈（第 0 层，直接崩溃位置），再输入 l 查看崩溃附近代码：

   (gdb) f 0

   #0 0x0000000000401206 in sdk_test_func () at test_nullptr.cpp:9

   7 void sdk_test_func() {

   8 string* str = nullptr; // 定义空指针

   9 cout << "SDK测试：" << str->c_str() << endl; // 空指针取值，触发崩溃

   10 }

   (gdb) l # 显示崩溃行及附近代码

5. info threads：查看崩溃时所有线程的状态（本示例为单线程，输出如下）：

   (gdb) info threads

   1 Thread 0x7f8a7a80d700 (LWP 12345) sdk_test_func () at test_nullptr.cpp:9

6. q：退出 gdb 交互界面（输入后直接返回终端）。

7. 补充：用 gdb 解析数组越界崩溃（示例2）

   若使用 test_array_sdk 的 Core 文件，解析步骤完全一致：gdb ./test_array_sdk core

   bt # 查看堆栈

   输出示例（明确数组越界位置）：

   #0 0x00000000004011e6 in sdk_array_func () at test_array.cpp:9

   #1 0x0000000000401226 in main () at test_array.cpp:14解读：崩溃在 test_array.cpp 第9行，对应数组越界代码，快速定位问题。

前提：已生成 Core 文件（core.test_sdk.12345），可执行程序为 test_sdk（带 -g 调试信息编译）。

1. 加载 Core 文件和可执行程序：

   gdb ./test_sdk core.test_sdk.12345执行后进入 gdb 交互界面，提示"Core was generated by `./test_sdk'."，表示加载成功。

2. 查看崩溃堆栈（测试人员核心操作）：

   bt输出示例：

   #0 0x0000000000401130 in main () at test.cpp:5

   #1 0x00007f8a7a60d555 in __libc_start_main () from /lib64/libc.so.6

   #2 0x0000000000401049 in _start ()解读：崩溃发生在 main 函数中，test.cpp 文件第 5 行（对应代码：int *p = nullptr; *p = 123; 空指针解引用）。

3. 常用辅助命令（测试必背）：

• bt full：打印详细堆栈，包含局部变量值；

• f 0：切换到崩溃的最上层堆栈（第 0 层，即直接崩溃位置）；

• l：显示崩溃位置附近的代码（需带 -g 调试信息）；

• info threads：查看崩溃时所有线程的状态（多线程程序适用）；

• q：退出 gdb 交互界面。

3.2.2 coredumpctl ------ 系统级 Core 管理与解析（适用于系统级程序）

作用

由 systemd 提供的 Core 管理工具，可收集系统中所有程序的 Core 文件，无需手动查找，支持直接解析 Core，适合系统级程序、后台服务的 Core 解析（测试场景中，若 SDK 是后台运行，优先用此工具）。

特点：自动记录 Core 生成的时间、程序信息、崩溃原因，无需手动设置 Core 保存路径。

安装方法

多数 Linux 系统（如 CentOS 7+、Ubuntu 16.04+）默认自带 systemd，无需额外安装；若未安装，执行：

CentOS

yum install systemd -y

Ubuntu

apt install systemd -y

实操实例（结合测试场景，基于前置崩溃示例）

场景：测试的 SDK 程序（test_nullptr_sdk）作为后台服务运行，崩溃后生成 Core，用 coredumpctl 管理并解析（无需手动查找 Core 文件）。

1. 后台运行崩溃程序（模拟后台服务场景）：

   ulimit -c unlimited # 开启Core生成

   nohup ./test_nullptr_sdk & # 后台运行程序，输出重定向到nohup.out

   程序后台运行后会立即崩溃，终端提示"[1]+ 段错误 (核心已转储) nohup ./test_nullptr_sdk"。

2. 查看系统中所有 Core 记录（筛选当前崩溃程序）：

   coredumpctl list test_nullptr_sdk输出示例（精准筛选 test_nullptr_sdk 相关 Core）：

   TIME PID UID GID SIG COREFILE EXE

   Tue 2026-03-28 15:30:00 CST 12345 0 0 11 present /root/test_nullptr_sdk解读：PID 为 12345 的 test_nullptr_sdk 程序，在指定时间崩溃，Core 文件已保存（present），无需手动查找路径。

3. 直接解析指定 PID 的 Core 文件（核心操作）：

   coredumpctl gdb 12345执行后自动加载 Core 文件和可执行程序，进入 gdb 交互界面，后续操作与 3.2.1 一致（输入 bt 查看堆栈）：

   (gdb) bt

   #0 0x0000000000401206 in sdk_test_func () at test_nullptr.cpp:9

   #1 0x0000000000401246 in main () at test_nullptr.cpp:14无需手动指定 Core 文件路径，coredumpctl 自动关联，适合后台服务、多程序同时运行的场景。

4. 导出 Core 文件（若需发给开发，精准导出当前崩溃的 Core）：

   coredumpctl dump 12345 --output ./test_nullptr_core将 PID 12345 对应的 Core 文件导出到当前目录，命名为 test_nullptr_core，方便压缩上传 Bug 系统。

5. 补充：用 coredumpctl 解析数组越界崩溃（示例2）

   后台运行 test_array_sdk 并崩溃后，执行以下命令即可解析：coredumpctl list test_array_sdk # 查看PID

   coredumpctl gdb 对应PID # 解析Core

   输出堆栈与 gdb 解析一致，可快速定位数组越界位置。

场景：测试的 SDK 程序（test_sdk）作为后台服务运行，崩溃后生成 Core，用 coredumpctl 管理并解析。

1. 查看系统中所有 Core 记录：

   coredumpctl list输出示例（筛选 test_sdk 相关）：

   TIME PID UID GID SIG COREFILE EXE

   Tue 2026-03-28 14:30:00 CST 12345 0 0 11 present /root/test_sdk解读：PID 为 12345 的 test_sdk 程序，在指定时间崩溃，Core 文件已保存（present）。

2. 直接解析指定 PID 的 Core 文件：

   coredumpctl gdb 12345执行后自动加载 Core 文件和可执行程序，进入 gdb 交互界面，后续操作与 3.2.1 一致（输入 bt 查看堆栈）。

3. 导出 Core 文件（若需发给开发）：

   coredumpctl dump 12345 --output ./test_sdk_core将 PID 12345 对应的 Core 文件导出到当前目录，命名为 test_sdk_core。

3.2.3 addr2line ------ 轻量地址解析工具（适用于无完整调试环境）

作用

轻量级命令行工具，仅用于将 Core 文件中的"内存地址"转换为具体的代码行（文件名、行号），不支持查看完整堆栈、局部变量，适合无 gdb 环境、或仅需快速定位崩溃行的场景（如发布版 SDK 无调试信息时）。

特点：体积小、操作简单，无需交互，直接输出解析结果。

安装方法

默认随 gcc 一起安装，若未安装，执行：

CentOS

yum install gcc -y

Ubuntu

apt install gcc -y

实操实例（结合测试场景，基于前置崩溃示例）

addr2line 核心用于"地址→代码行"转换，以下分两种场景（带调试信息、无调试信息），结合前置的两个崩溃示例，实操步骤可直接复制执行。

场景1：带调试信息的程序（test_nullptr_sdk 带 -g 编译），快速解析崩溃行

前提：已生成 test_nullptr_sdk 的 Core 文件，先用 gdb 获取崩溃地址（核心步骤）。

1. 先用 gdb 查看崩溃地址（仅需获取地址，无需深入调试）：

   gdb ./test_nullptr_sdk core

   bt # 输出崩溃地址，重点记录第0层堆栈的地址gdb 输出（提取崩溃地址 0x0000000000401206）：

   #0 0x0000000000401206 in sdk_test_func () at test_nullptr.cpp:9

   #1 0x0000000000401246 in main () at test_nullptr.cpp:14记录崩溃地址：0x0000000000401206（第0层堆栈，直接崩溃位置）。

2. 用 addr2line 解析地址（核心操作）：

   addr2line -e ./test_nullptr_sdk 0x0000000000401206输出示例：/root/test_nullptr.cpp:9解读：直接定位到崩溃在 test_nullptr.cpp 第9行，与 gdb 解析结果一致，无需进入交互界面，快速获取崩溃行。

场景2：发布版 SDK（无 -g 调试信息），解析函数名（需开发提供符号表）

模拟发布版场景：编译时不添加 -g 调试信息，再用 addr2line 解析。

1. 编译无调试信息的发布版程序（模拟真实发布场景）：

   g++ test_nullptr.cpp -o test_nullptr_sdk_release # 不添加 -g

2. 运行程序，生成 Core 文件：

   ulimit -c unlimited

   ./test_nullptr_sdk_release # 崩溃，生成Core文件

3. 用 gdb 获取崩溃地址：

   gdb ./test_nullptr_sdk_release core

   bt # 提取崩溃地址 0x00000000004011a6

4. 用 addr2line 解析地址：

   addr2line -e ./test_nullptr_sdk_release 0x00000000004011a6输出示例：?? ??:0 或 sdk_test_func (in /root/test_nullptr_sdk_release)解读：无调试信息时，无法解析具体代码行，仅能看到函数名（或无有效信息），此时需向开发索要"带调试信息的程序"或"符号表文件"，再重新解析。

场景3：解析数组越界崩溃（示例2），快速定位行号

用 addr2line 解析 test_array_sdk 的崩溃地址，步骤与场景1一致：

1. gdb 获取崩溃地址：

   gdb ./test_array_sdk core

   bt # 提取地址 0x00000000004011e6

2. addr2line 解析：

   addr2line -e ./test_array_sdk 0x00000000004011e6输出示例：/root/test_array.cpp:9，直接定位数组越界的代码行。

补充说明：addr2line 仅能解析"单个地址"，无法查看完整堆栈，适合快速定位崩溃行、无 gdb 环境的场景，测试人员可搭配 gdb 使用（gdb 查地址，addr2line 快速转代码行）。

场景1：带调试信息的程序（test_sdk 带 -g 编译），已知崩溃地址，快速解析行号。

1. 先用 gdb 查看崩溃地址（或从开发提供的日志中获取）：

   gdb ./test_sdk core.test_sdk.12345

   bt # 输出崩溃地址 0x0000000000401130

2. 用 addr2line 解析地址：

   addr2line -e ./test_sdk 0x0000000000401130输出示例：/root/test.cpp:5，即崩溃在 test.cpp 第 5 行。

场景2：发布版 SDK（无 -g 调试信息），仅能解析出函数名（需开发提供符号表）。

无调试信息时，解析地址

addr2line -e ./test_sdk 0x00007f8a7a60d555

输出示例：__libc_start_main (in /lib64/libc.so.6)，仅能看到系统函数，无法看到具体代码行，需开发提供带调试信息的程序或符号表。

3.3 三种工具的区别对比

对比项

gdb

coredumpctl

addr2line

核心功能

完整解析 Core，查看堆栈、变量、线程，支持调试

管理系统所有 Core，自动收集，支持 gdb 联动解析

仅将内存地址转换为代码行/函数名，功能单一

操作复杂度

中等（需进入交互界面，掌握基础命令）

简单（单条命令即可管理/解析）

极简单（单条命令直接输出结果）

适用场景

大多数测试场景，需完整堆栈

系统级程序、后台服务，Core 分散难查找

无 gdb 环境、快速定位崩溃行、发布版 SDK 初步解析

依赖条件

需可执行程序（带 -g 更佳）+ Core 文件

依赖 systemd，自动关联可执行程序和 Core

仅需可执行程序 + 崩溃地址

输出信息

完整堆栈、变量、代码片段

Core 管理记录 + gdb 解析结果

仅文件名+行号，或函数名

测试人员选择建议：优先用 gdb（满足绝大多数场景）；后台服务用 coredumpctl；无 gdb 环境用 addr2line。

第四章 测试人员 Core 处理与 Bug 提交规范

4.1 Core 处理流程（测试必遵循）

1. 复现崩溃：确认程序崩溃可复现，记录复现步骤（如"运行 ./test_sdk，输入参数 123，等待 5 秒崩溃"）；

2. 获取 Core：按第二章步骤，确保生成 Core 文件，保存到测试目录（建议命名规范：程序名_版本_PID_时间戳.core）；

3. 解析 Core：用 gdb（或其他工具）解析，获取崩溃堆栈（至少保存 bt 命令输出结果）；

4. 整理信息：收集程序版本、测试环境、复现步骤、Core 文件、堆栈信息；

5. 提交 Bug：将所有信息提交给开发，确保开发可快速定位问题。

4.2 Bug 提交必须包含的内容（核心规范）

• 问题标题：明确崩溃场景，如"Linux 环境下 test_sdk v1.0 输入非法参数后崩溃（Core 已提供）"；

• 问题现象：清晰描述崩溃表现，如"程序运行 3 秒后提示'段错误 (核心已转储)'，进程退出"；

• 复现环境：

  • Linux 系统版本（如 Ubuntu 20.04 LTS、CentOS 7.6）；

  • 系统位数（32 位/64 位）、CPU 型号（可选）；

  • SDK 版本（如 test_sdk v1.0）、编译方式（是否带 -g 调试）；

  • 测试工具、运行参数。

• 复现步骤：一步一步清晰描述，确保开发可复现，如：

  1. 在 Ubuntu 20.04 终端执行 ulimit -c unlimited；

  2. cd 到 /root/test 目录，运行 ./test_sdk -p 12345；

  3. 程序启动后，输入"test"，立即崩溃。

• 附件：

  • Core 文件（按规范命名）；

  • gdb 解析的堆栈截图/文本（bt 命令输出结果）；

  • 程序运行日志（若有）。

• 初步判断（可选）：根据堆栈信息，初步判断崩溃类型，如"空指针解引用""数组越界"。

4.3 测试人员注意事项

• 无需修改代码、无需深度调试内存，只需完成"复现→获取 Core→解析堆栈→提交 Bug"；

• Core 文件需与崩溃程序的版本完全匹配，否则开发无法解析；

• 测试环境中，Core 文件可暂时保留，确认开发已获取后可删除（避免占用磁盘空间）；

• 若解析不出具体代码行，需向开发确认：是否提供带调试信息的程序或符号表。

第五章 常见问题 FAQ（测试高频场景）

• Q1：程序崩溃了，但没有生成 Core 文件？

A：优先检查 ulimit -c 是否为 0（未开启 Core 生成）；其次检查保存路径权限、磁盘空间；最后确认是否为容器/沙箱环境限制。

• Q2：gdb 解析时提示"Core was generated by `./test_sdk' but the file is not executable"？

A：可执行程序（test_sdk）无执行权限，执行 chmod +x ./test_sdk 即可。

• Q3：addr2line 解析输出"?? ??:0"？

A：可执行程序未带 -g 调试信息，或崩溃地址错误，需重新获取崩溃地址，或让开发提供带调试信息的程序。

• Q4：Core 文件太大，无法上传 Bug 系统？

A：可压缩 Core 文件（tar -zcvf core.tar.gz core.test_sdk.12345），或让开发提供远程调试权限，直接在测试机器上解析。

• Q5：多线程程序崩溃，如何确定是哪个线程导致的？

A：用 gdb 输入 info threads 查看所有线程，带"*"的线程为崩溃线程；切换线程用 thread 线程编号，再输入 bt 查看该线程堆栈。

第六章 实操总结（最简流程）

测试人员日常操作最简步骤，记牢即可完成 Core 相关测试：

1. 开启 Core：ulimit -c unlimited；

2. 运行程序：./test_sdk（触发崩溃）；

3. 解析 Core：gdb ./test_sdk core → 输入 bt → 保存堆栈；

4. 提交 Bug：整理复现步骤、环境、Core 文件、堆栈，提交给开发。