第一阶段：现场还原（加载与定位）
首先，登录机器 33.9.120.103，进入 Core 文件所在目录。
1. 加载 Core 文件
bash
gdb /usr/local/bin/wings_worker /online/corefile/core-wings_worker-88-1767854342-ucpe-resource011012102176.na610
2. 查看崩溃信号与原因 进入 GDB 后，首先确认程序死于什么信号：
gdb
(gdb) info program
# 预期输出：Program terminated with signal 11, Segmentation fault (或 Signal 6)
3. 获取崩溃堆栈 直接查看当前线程（触发崩溃的线程）的调用路径：
gdb
(gdb) bt
第二阶段：深度分析（揪出 127TB 溢出）
4. 检查内存申请大小 切换到内存分配的帧（通常是 Frame 0），查看它到底想申请多少内存：
gdb
(gdb) f 0
(gdb) p $rdi
# $rdi 存储第一个参数。如果显示 140436855727216，说明申请了约 127TB，直接实锤溢出。
5. 确认“长度被误当成指针”的 Bug 切换到调用分配函数的上一层（通常是 Frame 1），查看寄存器：
gdb
(gdb) f 1
(gdb) info registers
# 检查 rdi (起始指针) 和 rsi (结束指针)
# 如果 rsi 是一个很小的整数（如 843），说明它把长度当成了内存地址。
第三阶段：数据取证（抓取异常 JSON）
我们需要拿到导致崩溃的那段原始数据。
6. 定位 JSON 字符串地址 切换到业务解析层（根据你之前的堆栈，是 Frame 22）：
gdb
(gdb) f 22
(gdb) info args
# 找到 str 变量，记录其 _M_p 的内存地址（假设是 0x7fb9e7a32018）
7. 导出 JSON 数据到文件 由于 JSON 可能很长，直接打印会刷屏，建议导出到文件：
gdb
# 导出前 50000 字节到当前目录下的 crash_case.json
(gdb) dump binary memory crash_case.json 0x7fb9e7a32018 (0x7fb9e7a32018 + 50000)
8. 在线查看关键位置 查看崩溃发生的偏移量（pos=1350）附近的内容：
gdb
(gdb) printf "%.200s\n", (char*)(0x7fb9e7a32018 + 1300)