BLE通信中内存越界问题的排查与修复

1. 问题背景与现象描述

在物联网设备的BLE（蓝牙低功耗）通信测试中，我们遇到了一个棘手的崩溃问题。具体表现为：在进行持续数据流传输（即"打流"测试）时，设备会概率性地发生系统崩溃。这种崩溃并非每次都能复现，但一旦发生就会导致整个测试过程中断，严重影响产品可靠性验证。

崩溃发生时，RTOS平台会生成core dump信息。关键线索是mepc寄存器中的PC指针值0x2300b948，指向了SDK内部的订阅管理模块。从现象上看，这像是典型的内存越界访问问题——但令人困惑的是，崩溃点位于原厂提供的SDK代码中，而非我们自行开发的业务逻辑部分。

提示：在嵌入式开发中，遇到第三方SDK导致的崩溃往往比自家代码崩溃更难排查，因为缺乏完整的代码上下文和理解。

2. 初步排查与问题定位

2.1 崩溃日志分析

通过objdump工具反汇编固件，我们定位到崩溃地址对应的源代码位置。关键崩溃日志显示订阅列表的尾节点指针异常地从NULL变成了0xd400。在BLE协议栈中，订阅列表用于管理特征值的通知/指示配置，其正确性至关重要。

c复制// 正常订阅列表结构示例
typedef struct {
    ble_sub_node_t *head;  // 链表头指针
    ble_sub_node_t *tail;  // 正常情况下应为NULL
} ble_sub_list_t;

2.2 测试范围缩小技术

为了复现这个概率性问题，我们设计了分阶段验证方案：

1. 在BLE连接、配对、休眠、ping测试、iperf测试等各阶段前后，插入订阅表状态检查点
2. 通过二分法逐步缩小可疑操作范围
3. 最终锁定问题出现在ping测试阶段

这个过程中有个重要发现：异常指针值（如0xdb00）与当时记录的RSSI（信号强度）数值高度接近。这为我们后续分析提供了关键方向。

3. 深入根因分析

3.1 内存布局关联性

通过比对内存映射文件，我们发现两个关键信息：

1. RSSI缓存数组（10个uint8_t元素）的地址为0x2000xxxx
2. 订阅表尾指针的地址为0x2000xx00 + 0xFF

虽然看似无关，但这个0xFF的偏移量在后来的分析中成为破案关键。

3.2 算法缺陷定位

问题最终