遭遇Heap溢出

十一月 10, 2007

今天凌晨配合云南移动进行局数据全量升级，本来以为是件很轻松的活计，甚至不需要我动手的事情，结果却又是一次惨痛的教训啊。

这个活计其实真的很简单，就是将数据库中的旧数据全部删除，然后导入新的数据，由于数据量较大需要重启一次我们的系统。问题就在重启系统上。摆在我面前的就是"重启失败"，系统dump一个core文件。通过pstack和gdb查看如下：
core 'core' of 7971: xxxxx -s
fe647b38 t_splay (3a71b0, 229, 228, 3a7000, 3ca548, 8000000) + 14
fe6475ec realfree (3ca320, 741f4, 320974, fe6bc000, 0, 3209a5) + c8
fe647e5c cleanfree (0, 7, fe6c29bc, 1a8, 3a7008, 0) + 54
fe646f88 _malloc_unlocked (ea60, 0, ff13de50, fe6bc000, ff184ae6, 0) + f4
fe646e78 malloc (ea60, 3e8, 0, 2, f8e9dacb, 1) + 20
000fa330 我们一业务函数，暂叫A_func吧 (18, 186a0, ffbfe4b0, 30330000, 37, ff00) + 1fc

碰到系统调用malloc出core，简单的初级的想法是：系统资源出现问题。使用df和top查看得知，物理内存居然有12G Free，而且出core的地方位于初始化阶段，系统大量使用内存的地方还未执行呢。

这个问题也真是碰巧了，A_func这个业务层接口恰恰是初始化我们今晨更新的局数据的接口，这又不由得让我去检验数据的有效性，经过回归数据，甚至是清空数据，问题依旧。

曾怀疑过内存对齐问题，但是自己明知道malloc出来的数据是经过编译器对齐的，经过测试后排除。

甚至怀疑这是Solaris的bug，在网上花了半个多小时搜索原因，未遂。每每当应用程序程序员遇到自己解决不了的问题时，都会归咎于操作系统。

在用户的多次催促下(大家知道电信的产品每年的宕机时间是有规定的)，无奈下退回到以前的版本，发现居然可以启动。这说明什么呢？首先今晨更新的局数据是没有问题的，系统资源也是没有问题的，操作系统也是无恙的。一个新的思路急至眼前，比对一下新版和旧版功能上的差别，只有一个新增功能。恰好，这个功能(这里暂叫B_func)对应的初始化就在A_func之前调用的。快速转移到B_func内部实现当中，哇，问题
找到了。

问题源于Heap的溢出，原因当然是编码不当，马虎所致，更精确的说是：copy & paste所致。
在B_func中在原生Heap上动态申请了一块内存，内存大小为n * sizeof(A_Struct); 之后在B_func中对这块刚申请的内存进行了一次'清零'操作。就是这次'清零'操作惹下了大祸：memset(ptr_to_mem_alloced, 0, n * sizeof(B_Struct)); 而sizeof(B_Struct) > sizeof(A_Struct)，这样大家就清楚了，由于'copy & paste'，heap上的'组织网络'被局部的摧毁了。之后再使用heap上的数据单元自然逃离不了灭顶之灾。

这段代码是一个来到公司的新员工所写，这个员工是社招，水平不赖。其实真的不能埋怨这位员工，通过这次事件感觉责任最大的还是我，只怨我当初在评审代码时因此处简单而未加仔细评审，否则这种问题早就会被消灭在萌芽中了，也就不会出现今天的事件了。

这里也要感谢在远方的云南移动的兄弟顶住了投诉的压力，让我有时间找到问题所在啊。

以下是摘自WIKIPEDIA的关于"heap overflow"的描述：A heap overflow is another type of buffer overflow that occurs in the heap data area. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. Exploitation goes as follows: if an application copies data without first checking to see if it fits into the chunk (blocks of data in the heap), the attacker could supply the application with a piece of data that is too large, overwriting heap management information (metadata) of the next chunk. This allows an attacker to overwrite an arbitrary memory location with four bytes of data. In most environments, this may allow the attacker control over the program execution.