前言

• 最近在开发调试基于RT-Thread 的驱动时，遇到一个比较奇怪的死机问题，后来经过一步步排查，终于发现是驱动的链表节点没有初始化造成的死机

问题分析

• RT-Thread 的驱动开发完成后，通过编写串口 shell 测试命令，运行命令后，触发死机

• 由于当前缺少单步的调试方法，只能通过增加LOG与打开关闭部分软件功能，一步步缩小范围

• 在函数调用的入口，把某些关键的函数调用分别注释掉验证，这样逐步验证下来，最终缩小到一个函数，调用这个函数就触发死机。

用到的软件调试方法

（1）增加LOG，确认代码能执行到哪些函数，能执行到哪些行

（2）通过 #if 0 A_CODE #else B_CODE #endif 条件编译的调试方法，大块注释部分代码，确认代码执行的路径，缩小排查方向，确认是执行到哪个函数或模块造成死机的

（3）通过对比代码来确认问题，比如软件正常工作过，后来改动死机了，大概率说明是改动造成的，所以可以通过 git BCompare.exe 等代码管理与比对工具，代码回溯，两份新旧代码对比分析，逐步把排查范围缩小，从代码层面分析可能造成死机的原因

问题分析

• 软件调试有时候比较的简单，有时候会比较的复杂，由于这个驱动移植来自其他系统的，数据结构里面的成员比较的多，所以初步通过代码对比工具如 BCompare 进行代码对比，发现了一点端倪：由于RT-Thread 暂时不支持 hash list（哈希链表），我把 hash list的功能实现 改为了 RT-Thread 的 list 替代，struct rt_list_node。

• 对比了软件的其他改动点，虽然改动部分较大，但软件工作流程差不多，初步排查代码没有实质性的差异

• 通过进一步的排查并缩小范围，终于发现了问题点：这个函数在 插入链表 的操作部分死机了！

• 通过代码继续网上找，发现这个包含 RT-Thread list 的数据节点，是通过 rt_malloc 申请的，并且没有看到成员 list 使用 rt_list_init 初始化链表的操作

• 所以马上确认了问题： 链表的节点没有初始化造成的，通过增加 list 初始化，本以为立即解决了问题，但是竟然依旧死机！

• 意外的BUG发现：数据节点的链表的头，也就是 链表 head 也没有初始化，解决方法同上，需要初始化 链表的头：使用 rt_list_init，这样问题得到解决

• 移植的代码之前使用的 hashlist，声明时即初始化了，不需要显示的初始化，而RT-Thread list，必须初始化，否则把链表节点插入 链表头部的时候，就会出现 野指针或空指针 访问成员的问题，肯定会出问题。

• 解决方法就是 增加链表初始化操作

问题回顾

• 由于先前移植的样板驱动使用的是 hash list，造成移植后没有初始化数据结构的链表节点，触发了死机。所以驱动移植时，遇到链表时，一定要注意 链表头与链表节点的 链表初始化问题

• 另一个注意点：操作空指针的成员，异常信息里面，可能会提示 异常出在一个 较小的 内存地址上。所以遇到死机，并且发现死机的 内存地址很小，可以往 空指针方向排查

• RT-Thread 双向循环链表的操作，由于使用的是【宏定义】，也就是链表操作函数本身没有判空的操作，用户需要有链表指针判空的操作。

• 访问一个空指针的结构体成员，肯定会触发内存异常死机。 如 buffer->list 中的 list 为 RT_NULL，那么访问 buffer->list->next 时候，list 中的 next 成员地址就是非法的内存地址（小地址），就会出现异常死机

小结

• 链表操作需要谨慎，不只是要把 链表头 申请为 全局的，而且每个链表的节点，都是需要全局的。

• 注意链表节点会嵌入到一个复杂的数据结构里面，并且使用动态内存申请的方式 创建，这是一定要注意不要漏下 链表成员的初始化。