| name | coredump_diagnose |
| description | 面向 Linux 用户态 coredump（core 文件）的结构化诊断技能。适用于进程崩溃、SIGSEGV/SIGBUS/SIGABRT/SIGFPE、空指针、栈溢出、内存破坏、总线错误、除零、Python+C 混合栈等场景；当用户提到 core、coredump、gdb 分析崩溃、段错误、总线错误、生成 core、应用转储时应触发。依赖系统已安装 GNU gdb；报告日志默认写入 /tmp/core_diag/。 |
Coredump 诊断
目标
在最短路径内完成 core 可用性校验、全量信息采集与场景归类（含 SIGBUS 等与 SIGSEGV 不同的分支），并按场景下钻给出可验证的崩溃链与根因假设；输出统一的报告日志路径（绝对路径）便于归档与自动化。
技能目录结构
coredump_diagnose
├── scripts
│ ├── pre_check.sh
│ ├── collect_and_classify.sh
│ ├── analyze_nullptr.sh
│ ├── analyze_stack_overflow.sh
│ ├── analyze_memory_corrupt.sh
│ ├── analyze_sigbus.sh
│ ├── analyze_abort.sh
│ └── analyze_divzero.sh
└── SKILL.md
以下命令默认在技能根目录 coredump_diagnose 下执行（或把路径写成仓库内的绝对路径）。
总流程（四阶段）
- 第一阶段：前置环境检查与二进制发现（
pre_check.sh）
- 第二阶段：信息收集与场景指纹归类（
collect_and_classify.sh）
- 第三阶段：按场景深度下钻（
analyze_*.sh）
- 第四阶段：反思与交叉验证 → 输出根因分析结论
第一阶段：前置环境检查
检查内容
| 项 | 说明 |
|---|
| GDB 可用性 | 验证系统是否安装 gdb，无则无法继续 |
| Core 合法性 | coredump 是否存在、可读 |
| 二进制发现与校验 | 支持 --binary 手动指定；未指定时从 core 头信息尝试提取可执行路径，并校验存在、可读 |
| 调试符号 | 粗查是否含 -g 调试信息，无符号时提示行号可能缺失 |
脚本执行命令
bash ./scripts/pre_check.sh --core <coredump 文件路径> [--binary <崩溃程序绝对路径>]
产出
- 终端打印
CORE_PATH、BINARY_PATH（绝对路径，可直接复制给后续脚本）
- 自动发现的二进制路径会缓存在
/tmp/.coredump_auto_bin.tmp（供同一会话逻辑使用）
第二阶段：信息收集及分类
采集内容（写入报告日志）
- 程序与信号：终止原因、系统信号、崩溃地址
- 完整 C 层调用栈：栈帧关系、
bt full、局部变量与函数入参
- 寄存器：通用寄存器与 PC 现场
- 反汇编：崩溃指令前后汇编，辅助指令级定位
- 内存映射：堆、栈、共享库范围，用于判断地址是否合法
- 全线程：各线程状态与栈，排查并发问题
- Python 增强（可选）：自动尝试
py-bt、py-locals（需 python3-dbg / python3-debuginfo 等，失败会降级提示）
脚本执行命令
bash ./scripts/collect_and_classify.sh \
--core "<前置检查输出的 CORE_PATH>" \
--binary "<前置检查输出的 BINARY_PATH>"
GDB 调用约定（与脚本实现一致）
collect_and_classify.sh 与各 analyze_*.sh 使用 gdb --quiet --batch -x <临时脚本>：命令写入临时文件，避免部分环境下 --batch 从 stdin 读命令不稳定；小节标题用 Python gdb.write。会话输出由 shell 重定向 写入报告日志（不在 GDB 内 set logging 与重定向混用）。
产出说明
| 产出 | 说明 |
|---|
| 报告日志 | /tmp/core_diag/collect_and_classify_<时间戳>.log（自动 mkdir -p /tmp/core_diag） |
| 摘要 | 场景分类与「下一步推荐命令」经 tee 追加到同一日志；终端打印摘要并输出 报告日志绝对路径:（realpath） |
场景指纹 → 归属（本步自动分类）
| 条件（基于 GDB 日志解析） | 场景 | 下一步脚本 |
|---|
SIGSEGV 且故障地址为 0x0 | 空指针 | analyze_nullptr.sh |
SIGSEGV 且栈深度 > 50 | 栈溢出 | analyze_stack_overflow.sh |
SIGSEGV 且非 0x0 的非法地址 | 内存破坏/野指针/越界 | analyze_memory_corrupt.sh |
SIGBUS（且未落入空指针/深栈分支） | 总线错误 | analyze_sigbus.sh |
SIGABRT | 主动终止/堆损坏/异常 | analyze_abort.sh |
SIGFPE | 算术异常（如除零） | analyze_divzero.sh |
SIGILL / SIGSYS / SIGXCPU / SIGXFSZ 等 | 少见信号（other） | 无专项；通读收集日志人工分析 |
| 其余未列信号 | unknown | 人工研判 |
路径提示：collect_and_classify.sh 内嵌的下一步示例可能为 ./skills/...；实际执行请统一使用 bash ./scripts/analyze_*.sh（在技能根目录下）或仓库内绝对路径。
第三阶段：按场景深度下钻
原则：先验证「现象与信号是否一致」，再解释「地址/栈为何指向该场景」，最后界定「需代码侧补证的部分」。
各 analyze_*.sh 的报告日志为 /tmp/core_diag/analyze_<场景>_<时间戳>.log，结束前终端打印 报告日志绝对路径:。
场景 1：空指针访问（analyze_nullptr.sh）
脚本执行命令
bash ./scripts/analyze_nullptr.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
在崩溃栈顶帧（Frame 0）对齐源码与变量，确认触发访问的指针名及对应代码行。结合 disas 区分本次段错误是由读还是写访问触发，避免误判为「仅读」或「仅写」类问题。沿调用栈向上追踪该指针的来源，区分函数入参、未初始化局部变量、全局或静态对象被置空等路径。最后将 GDB 结论映射回源码，标出缺少非空校验或错误分支未覆盖的位置，作为修复与单测依据。
判定标准：SIGSEGV，且崩溃时访问地址为 0x0。
场景 2：栈溢出（analyze_stack_overflow.sh）
脚本执行命令
bash ./scripts/analyze_stack_overflow.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
结合浅层与深层栈片段（如 bt 20 / bt -20）观察栈深度与是否存在同一符号反复出现的递归模式。在栈顶帧检查 info locals，识别过大的栈上数组或结构体导致栈帧耗尽。若为递归，重点审查终止条件与边界输入，解释为何未能正常退出。同时保留对栈越界写的怀疑：异常深的栈或损坏的返回地址可能与此相关，需对照源码与反汇编排除。
判定标准：SIGSEGV，且第一步分类中栈层数 > 50，或日志与源码共同指向超大栈上对象/深度递归。
场景 3：内存破坏 / 野指针 / 越界访问（analyze_memory_corrupt.sh）
脚本执行命令
bash ./scripts/analyze_memory_corrupt.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
将崩溃地址与 info proc mappings 对照，判断其落在堆、栈、映射库还是未映射区，区分「合法区域内的非法访问」与「完全野地址」。在 x86_64 上结合 RDI/RSI/RDX 等参数寄存器及其指向内存的转储，判断数据是否像已释放、未初始化或垃圾值。用带机器码的反汇编锁定具体访存指令，推断非法地址是在本条指令形成还是更早被写坏。最后从时间顺序上优先怀疑崩溃前最近的写操作，排查越界、UAF、双重释放与未初始化指针等典型根因。
判定标准：SIGSEGV，且访问地址非 0x0，常见为随机值、已释放堆块附近或明显非法区间。
场景 4：程序主动终止（analyze_abort.sh）
脚本执行命令
bash ./scripts/analyze_abort.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
从完整栈与多线程栈中区分三类典型路径：malloc/free 路径上的堆损坏（如 malloc_printerr、__libc_message）、C++ 异常路径（如 __cxa_throw、未捕获异常）以及显式 abort/断言失败。若为堆问题，集中审计近期分配释放配对、越界写堆块元数据、double free 等。若为 C++ 异常，尽量定位异常类型与抛出栈，并检查是否缺少 catch 或在析构中二次抛掷。结合业务逻辑确认 abort() 或断言的触发条件是否与配置、输入或资源失败一致。
判定标准：SIGABRT，且栈上常出现 __GI_abort、__libc_message、__cxa_throw 等特征符号（以实际日志为准）。
场景 5：算术错误 / 除零（analyze_divzero.sh）
脚本执行命令
bash ./scripts/analyze_divzero.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
在崩溃点附近反汇编中定位 div/idiv 及与之相关的数据移动，确认哪个寄存器或内存槽位作为除数。对照 info registers 与 info locals，核实除数是否为 0，并区分整型除零与取模 % 触发的 SIGFPE。沿数据流向上追问 0 的来源，区分计算溢出、默认值未改写、外部参数未校验等。修复上除崩溃点旁加判断外，更建议在数据入口或不变量处保证除数非零，并补充回归用例覆盖边界。
判定标准：SIGFPE，且崩溃点对应除法或取模，除数为 0。
场景 6：总线错误（analyze_sigbus.sh）
脚本执行命令
bash ./scripts/analyze_sigbus.sh \
--core "<CORE_PATH>" \
--binary "<BINARY_PATH>"
方法论
SIGBUS 与 SIGSEGV 的区分要点：总线错误往往是 CPU/内核对本次访存请求的拒绝（对齐、映射后端失效等），不仅限于「页内合法但权限错」这类典型段错误语义。生产环境中常见两类：一是 ARM 等架构下的未对齐访问；二是 mmap 映射文件被截断、删除或磁盘空间耗尽 导致映射区访问失效。排查时应 先确认运行架构与对齐约束，再对照 info proc mappings 将崩溃地址与 文件映射（含 MAP_SHARED）、匿名映射关联，并回溯业务侧 大文件 IO / mmap 路径。在排除对齐与映射类问题后，再考虑 物理内存异常、内核/驱动 等更底层原因。
判定标准：SIGBUS（第一步分类为 sigbus），且日志与反汇编、映射共同指向 对齐或映射/文件后端 相关问题（以实际采集为准）。
第三阶段产出要求
- 每个子场景日志内应具备：栈证据、寄存器/反汇编证据、与场景判定的一致性说明
- 明确列出需对照源码的待证命题（例如「某指针在何分支被置空」）
第四阶段：反思与交叉验证
目标：避免「单条栈或单次信号」定根因，确保结论可反驳、可补证。
4.1 反思方法论
- 区分 症状（信号、崩溃地址）、机制（哪条指令、哪段内存）、根因（代码路径、生命周期、并发假设）；勿将症状直接写成根因。
- 质疑当前主场景：例如「看似野指针是否实为截断后的空指针」「
SIGABRT 是否为 OOM/abort 钩子而非堆损坏」。
- 证据不足时显式保留不确定性，列出「待补证据」（符号包、复现条件、同版本二进制）。
4.2 交叉验证方法论
- 信号 ↔ 栈：
SIGSEGV 的地址与 maps 是否一致；SIGBUS 是否与未对齐、文件映射截断/mmap 路径一致；SIGABRT 是否真来自断言/堆检查。
- 多线程：
thread apply all bt 是否与单线程假设矛盾。
- 构建信息：无调试符号时，结论置信度降级，并建议
-g 重编或安装 debuginfo。
- 独立源：若仅有 GDB 输出，建议补充同一崩溃点的应用日志、系统日志（时间对齐）。
第五阶段：输出根因分析结论
按以下模板输出最终结论；缺失项标注 待补证据。
## 用户态 Coredump 根因分析结论
### 1) 基本信息
- 崩溃进程：<名称 / PID 若可知>
- Core 文件：<路径>
- 分析二进制：<路径>（是否与 core 匹配：是/否/待核实）
- 报告日志：<collect / analyze 的 /tmp/core_diag/*.log 绝对路径>
### 2) 崩溃事件链（Crash Chain，按时间/因果而非诊断步骤）
- C0：<加载/启动/输入 若可知>
- C1：<首次异常条件，如空指针解引用、除数为 0>
- C2：<信号与现场，如 SIGSEGV @0x0>
- C3：<若涉及库/线程，扩大影响或二次失败>
### 3) 根因链（Causal Chain）
- 直接原因：<例如对空指针解引用>
- 中间机制：<例如未校验返回值即解引用>
- 深层原因：<例如错误分支未覆盖、并发下对象已释放>
- 触发条件：<输入/配置/竞态/特定构建>
### 4) 证据清单（支持 / 反证）
- 支持证据：
- <GDB 日志片段：信号、Frame 0、地址>
- <反汇编或寄存器与结论一致处>
- 反证与排除：
- <已排除场景 + 理由，如非栈溢出因栈深度正常>
### 5) 结论置信度
- 置信等级：<高/中/低>
- 置信依据：<符号是否齐全、是否可复现、是否多源一致>
### 6) 修复与预防
- 即时修复：<代码/配置层建议>
- 长期治理：<静态检查、Review 点、测试用例、监控探针>
- 验证方式：<复现步骤关闭后应观察到何现象>
约束与提示
- 本技能针对 用户态 core + GNU gdb；内核 vmcore 请使用专用 crash/vmcore 流程。
- 无
--output：所有报告均落在 /tmp/core_diag/，文件名含脚本名与时间戳；以终端打印的 realpath 为准归档。
- 各分析脚本已统一为
-x 临时脚本；若某环境仍有异常，检查 GDB 版本 与 core/可执行文件路径是否匹配。
