数组越界是一颗隐形炸弹

数组越界问题大家在软件开发过程中应该都司空见惯了。如果你没见过,大概率是一个新手,工作经验不足,倒不是说你自己会生产这种 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 文件即可。

因此,操作数组时,一定要时时刻刻检测数组的索引的大小,以防越界。

声明:本内容为作者独立观点,不代表电子星球立场。未经允许不得转载。授权事宜与稿件投诉,请联系:editor@netbroad.com
觉得内容不错的朋友,别忘了一键三连哦!
赞 1
收藏 2
关注 156
成为作者 赚取收益
全部留言
0/200
成为第一个和作者交流的人吧