一个变量引发的血案

在嵌入式设备的开发中，经常利用看门狗对系统异常状况进行监测，以便在异常发生后，能用Reset这一便捷有效的手段使系统回归到安全状态。有时为了保证系统能回到一个确定状态，我们也会在合适的时机进行手动Reset，并且设法保证Reset过程中能够保留我们需要不去破坏的内容。但是在笔者所处的质量管理中，Reset被定义为非常严重的Bug。在大型项目开发中，负责开发各部分模块的人员数量可观，水平参差不齐，难免有互相影响而导致Bug的情况，造成Reset的状况也不胜枚举。

在近日的开发中，发生了一起制品无端Reset的事件。于是产生了如下一系列调查历程。

【1】由于对制品机能的要求，在之前的软件版本中，最新加入了手动（软件主动）Reset动作。首先怀疑Bug是由于手动Reset异常而产生。但是通过断点调式，很不幸不是在这里Reset的。


【2】只能怀疑是看门狗超时导致整个系统Reset。通过事实验证，确实是系统中发生了异常，导致看门狗超时。而制品使用了RTOS，发生异常时可以查看异常的原因，因此进一步确定该异常是由于不正确的内存访问导致的。


【3】通过软件Trace，判断不正确的内存访问，出现在RTOS的消息内存池的资源获取处理中……进一步跟踪异常源，发现是一个异常值出现在该区域，被当作地址处理，导致不正确的内存访问。由于该异常值不稳定，多次再现结果各不相同。


【4】根据对汇编指令的反跟踪，确定该异常值是从另一处内存区域取得的。而该区域，是这个内存池相对应的标志链表。


【5】出于对制品软件的信心，初步断定是制品软件有越界访问行为，改写了RTOS使用的内存区域。设定条件断点，当有对此处写入较小值时暂停程序。可是多次再现的结果显示，该异常值出现的位置也不是固定不变的。由于这块内存范围较大，异常值的取值范围也很广，因此条件断点最终没有对问题调查起到有效的帮助。


【6】继续分析，得知该标志链表中正常数据，都是类似0xFFFXXXXX的数值（有效的内存范围），导致Bug的异常值，是一个较小值（非有效内存范围）。此时对整个标志链表的内存区进行浏览，发现一处集中了较多异常值的区域。对该区域的值进行辨认，发觉与系统中某模块的通信数据相似。


【7】找来该模块负责人进行确认，确定了这些异常数据确实属于该模块。至此，确定问题发生的直接原因是该模块数据访问越界。


【8】由该模块进行调查，发现相关的数组的index变量（全局变量）值出现异常。再对此值的改写设定条件断点。最后确定问题发生在如下一段异常处理的代码（仿）处。

if((--index) < MAX_BOUND)
{
	index = INDEX_INIT;
}

而该index变量是一个字节的整形无符号变量。

当index为0时，进入该代码段，经过自减变为0xFF，而MAX_BOUND的值设定为数组的有效边界30，导致判断为F而没有进行index = INDEX_INIT的处理。

在后续的处理中，该0xFF终于酿成了Reset的大祸。


对于变量的处理，尤其是作为数组的下标，排除被他人误改写的情况，在使用过程中一定要时刻保证其在有效的范围内。对它的任何一次变更，一定要进行有效的判断并对异常值进行复位，不将错误留到下一刻。


分享此代码及调查过程，共同引以为鉴。