你碰到过的最难调试的 Bug 是什么样的?
author:一佰互联 2019-05-26   click:186

当年做x86 BIOS,客户是长城电脑。有一回我们的新版本发布给他们后进行系统重启测试,就是安装好操作系统后反复不停的重启机器,看看重启几百上千次后情况如何。原因是客户买了电脑每天用,至少得保障人家用个俩三年没事吧。


     结果我们的新版本重启到一百多次的时候挂了,现象就是开机黑屏,没有任何输出,就和当年的CIH病毒发作一模一样,经验判断系统压根还没有boot OS就跑飞了,我们自己测试也是这样,而且一旦出现问题就只能重新刷BIOS


        这个bug非常难调,因为当时我们的版本将近300万行源代码,大概2%的汇编与98%的C,几千个源文件,光是用来参与build过程的工具就有十几个。而且这些工具都是自己写的,构建项目的时候先编译这些工具,再去用这些工具加编译器来生成最后的ROM文件


    并且更加恼人的是,我们当时没有source level的debug tool,甚至连汇编级别的单步调试工具也没有,压根没法对代码做step into/over,更没法加个断点。。。当时可以用来调试BIOS的工具有两个,一个是Intel自己内部用的ITP,这个是人家公司自己的,一般不给外面人用,当时我们公司与I公司的关系尚处蜜月期,给了我们两个,但是当时被Chipset team霸占着做porting用;另一个工具就是American Arium(这家鸟公司不知道现在还活着不),这个东西说白了就是商品化的ITP,因为目标客户少,所以价格巨贵巨贵!一套系统价格几万美金,而且每一代CPU都要换一个插座上的适配器,这个适配器又是一万美金好像,还不太稳定,用着用着就挂了。。。我们公司当时有俩,但是因为没有买新一代处理器的适配器,于是只能吃灰了


     于是我们唯一的调试手段就是serial debug,就是系统启动的时候会通过port 80把一些重要信息打出来,然后我们根据这些信息判断执行到哪里了,系统的情况如何。这类似原始的printf打印。如果要看一个变量的值或者验证一下我们的判断,就得重新写代码,在需要的地方加入调试语句,然后花上半个小时rebuild bios,再重新烧录,再上电运行看看打出来的到底是啥。如果有疑问,或者发现这里没有问题,又或者有了新的思路,重复上述过程。记忆中整整一个礼拜,我们都在不停的看debug info,反复烧录bios 哭啊!简直不是人过的日子!


    最后发现系统可以成功的跑过PEI,到了DXE阶段的某个环节,突然就像心脏骤停一样,跑飞了!去看疑似跑飞的DXE Driver,是个很普通的平台硬件初始化程序,没什么疑点,压根没有头绪。那段时间,几乎每时每刻都在想着这个bug,实在是茶饭不思,根本没心情做任何事!


     就这样差不多过了俩礼拜,经过了无数次的重启与烧录bios,以及猜测,验证,被否定,再猜测,再验证,再否定。。。。。的过程后,我们终于发现了问题的原因:


   大家可能还记得电脑主板上有个CMOS,传统上用来存bios设置,但是现代的系统已经逐渐弃用这个东西。我们现在的bios芯片都是可擦写的,也就是用程序可编程。bios大小是8MB,里面会规划好,哪里是code,哪里放设置等等,然后代码里有专门写flash的函数,让大家可以保存一些东西,比如你想用硬盘还是光驱启动等等。同时系统每次启动也都会自己写一点没什么鸟用的信息进来。


    问题就出在这个写flash的函数上,我们后来发现,这哥们算错了存储区域的地址,导致写很多次后终于越界,误写到了人家代码区,把人家好端端的代码给写的乱七八糟,就如同当年CIH破坏系统的方法一模一样,照这样哪个机器能点亮才怪呢!又因为每次系统写的信息不一样,比如启动时间就不太一样,所以越界需要的次数不是恒定,更加重了我们排错的难度,泪啊!