数组越界问题大家在软件开发过程中应该都司空见惯了。如果你没见过,大概率是一个新手,工作经验不足,倒不是说你自己会生产这种 BUG,但有些同事却可能是 BUG 搬运工。
在鱼鹰五年的工作开发过程中,除了在北京刚毕业那会没遇到这种隐藏问题(碰到的都是自己生产的 BUG,不过自产自销,也还行),在深圳的这几家公司都遇到了数组越界的问题。
问题一
第一个问题是关于串口驱动导致的越界(最终结果是 hardfault),这个鱼鹰在以前的笔记中也反复强调了,因为这个问题差点导致自己熬了一个通宵,也是醉了(老代码的一个 bug)。
当然这个问题的解决和当时没有在线调试环境(当时的 PCB 板子通过串口烧录代码,没有调试接口,大坑)有很大关系,否则解决起来会快不少。
当然当时鱼鹰也没掌握这个方法《BUG 终结者,现场抓获!|颠覆认知》,否则出现问题时,这种小问题分分钟定位它。
所以当时解决这个问题,全靠玄学:运气。
否则这个问题不知道要蹂躏鱼鹰多少天。
问题二
这个问题在前东家遇到。当时的环境是 boot + app 形式。boot 代码也是跑了多年的老代码,从来没有出现过问题。
直到有一次版本升级,发现程序不能跳转到 app 正常运行(具体细节不记得了)。
当时有同事怀疑是我当时更新的 printf 打印函数有关系,因为当时的版本更新有这个改动。但鱼鹰对自己写的代码还是比较有自信的,并且我的 printf 改动和 app 跳转能有什么关系。
但怀疑到你头上了,同时鱼鹰也经常负责定位这类疑难杂症,刚好空闲,那就去瞧瞧看了,证明一下这不是你的问题。
因为问题 100% 复现,又掌握了那个现场抓获的技巧,很快就定位到是 boot 的一段代码申请的栈数组空间不足,导致被调用的函数使用这块空间时越界了。
类似下面这种:
func2(uint8_t *buff)
{
i = 5;
buff[i] = 0;
}
fun1()
{
uint8_t buff[4];
func2(buff);
}
当然实际代码肯定不可能这么简单,i 的值是变化的,不可能一眼看出。
这个问题也是导致 hardfault(退出 func2 时,破坏了返回地址)。
看到没有,有时候二分法(二分查找有问题的代码提交)查找问题也不是那么可靠,因为问题可能根本不在新提交的的代码中。
而下面的问题三也证明了这一点(当然不是说二分法没用,只是不能全靠它作为你的结果判断)。
问题三
这个问题是现东家遇到的问题。
自己开发的一个新模块,当合并到主分支时,发现开机必定 hardfault,这让我百思不得其解。自己新加入的代码,都没用到数组,怎么会hardfault。
我的第一反应就是,不是我的锅。
但问题出现在我合并的过程,也只能由我定位了。还好经验丰富,一天时间+加班几个小时,总算是定位到了。
这个问题定位有几个难点:
1、使用 C++
2、使用 O2 优化,而使用 O0 的方式问题不复现了(最蛋疼)
3、使用了 map 库函数
因此在复现率很高的情况下,还是花了这么多时间。
但好在顺利解决了(这么高的复现率,定位root case只是时间问题,信心也是 100%)。
简单来说,是以前的一段代码在使用 sprintf 时(这里强烈建议用 snprintf),导致栈缓存空间越界,然后导致上一层函数的局部变量被篡改,而这个局部变量会导致 map 传入的参数有问题,最终导致了 hardfault 。
可以看到,虽然根因在一个函数中,但最终出现问题却可能在另一个函数中。
就像犯罪现场,作案现场只有一个(root case),但可能案发现场并不是作案现场。
因此解决 bug 过程其实就是警察破案,通过蛛丝马迹找到第一作案现场,如此才能正确破案。
而这种代码在工程里面有好几处.....并且在合入我的代码之前,运行良好。所以,数组越界也不一定会 hardfault,就看你破坏的是啥了。
为什么?
大家很奇怪,为毛数据越界大部分情况下会 hardfault,有时却不会产生问题。只有思考到更深层的原因,你才能在 BUG 环绕中有所成长。
这个时候,就看你的基础扎实不扎实了。
这里来个简单示意函数(优化O0)
void func2()
{
int i = 0;
int buff[4];
buff[4] = 0;
}
void func1()
{
int j = 0; // 假设该局部变量使用 r4
func2();
}
栈空间如下(因为只有 4 个字,编译器可能 buff[4] 直接使用寄存器了,但为了简单说明,这里假设 buff 都使用了栈):
从上图我们可以知道,进入 func2 函数时,先 push,离开时 pop。
局部变量 i 使用 r4 寄存器,但是栈空间 r4 保存的是 func1 使用的 j 的值。
因此,当我们数组越界时(一般越界是往高地址,因为数组索引一般是自加),很容易破坏上一个函数的栈空间,在这里破坏的是 j 的值。如果 j 很重要,那么很可能会导致 hardfault 或者其它问题(能引起 hardfault 反而是好事)。
并且这里面还有重要的返回地址 lr,如果这个值被越界破坏,那么大概率都是hardfault,因为你企图跳转到一个不存在的地址执行。
数组越界是一个很危险的 BUG,能观察到现象还好,万一是默默破坏而不能很快被察觉,成为一个隐藏 BUG,那才是最危险的。
那为啥问题三增加别的代码会触发这个 BUG ,修改优化等级又会消失呢?
这和编译器有关系,有可能你的代码导致有问题的代码使用了不同的内存布局,从而越界篡改的位置变成了重要的内存,因此出现了现象,而优化等级对栈内存布局更是有很大影响。
另外本篇笔记介绍的局部缓存数组的越界,实际上还有全局数组的越界,那种问题相对简单许多,看 map 文件即可。
因此,操作数组时,一定要时时刻刻检测数组的索引的大小,以防越界。