遭遇Heap溢出

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

这个活计其实真的很简单,就是将数据库中的旧数据全部删除,然后导入新的数据,由于数据量较大需要重启一次我们的系统。问题就在重启系统上。摆在我面前的就是"重启失败",系统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. 

读'代码修改艺术',可观其大略

早在几个月前就从网上下载到了"Working Effectively With Legacy Code"这本书的E版,之所以下这本书是因为看到了"Legacy Code"这两个单词了,说实话当时我并不知晓这本书的价值,只是想当然的认为:这本书可能会有助我改善我所从事的项目中的"Legacy Code"。早在上个月去逛书店时,就看到了书架上的这本"修改代码的艺术",遗憾的是没有给予足够关注。在最近看到这本书译者刘未鹏的博客以及Dreamhead关于这本书的评价后,才又从电脑中找到这本书开始翻看。从与这本书几次"擦身而过"的经历来看,自己识书的能力实在是差劲。

我需要这本书,首先是因为我目前的项目中就有大量大量的"Legacy Code",所以我已经开始迫不及待的想看完这本书了。但是翻看一些后,我觉得作为使用C的开发者独观其大略即可。为什么呢?书中代码多以面向对象的语言Java或C++作为例子代码,很多细节对使用结构化语言的开发者意义不大。毕竟结构化的思想与面向对象的思想有着较大的差别。

作者提出来的修改软件的四个起因基本上大家都是应该认同的:
(1) 添加新特性;
(2) 修正bug;
(3) 改善设计;
(4) 优化资源使用。

同时作者又给出了为了减少修改行为带来的风险而应该考虑的三个问题:
(1) 我们要进行哪些修改?
(2) 我们如何得知已经正确地完成了修改?
(3) 我们如何得知没有破坏任何(既有的)东西?

在第一部分第二章的最后作者给出了一个解决这些问题的算法:
以下算法可以用于对遗留代码基进行修改:
(1) 确定改动点;
(2) 找出测试点;
(3) 解依赖;
(4) 编写测试;
(5) 修改、重构。

看完这些我觉得就可以直接进入第二部分了,作者给出了细致的、具体的面对不同情形应该如何去做。建议:在读每一个章节之前先回顾一下自己是否遇到过类似情形,自己当时是如何做的,当时的做法是否有改善的地方,哪些是值得发扬广大的,哪些是应该摒弃的,如果是现在我还会如何去做?之后,再看看Michael Feathers是如何去做的,这样效果应该是很好的。有如下这些情形值得我们去考虑:
(1) I Don’t Have Much Time and I Have to Change It 时间紧迫,但必须修改
(2) It Takes Forever to Make a Change 漫长的修改
(3) How Do I Add a Feature? 添加特性
(4) I Can’t Get This Class into a Test Harness 无法将类放入测试用具中
(5) I Can’t Run This Method in a Test Harness 无法在测试用具中运行方法
(6) I Need to Make a Change. What Methods Should I Test? 修改时应当测试哪些方法
(7) I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved? 在同一地进行多处修改,是否应该将相关的所有类都解依赖
(8) I Need to Make a Change, but I Don’t Know What Tests to Write 修改时应该怎样写测试  
(9) Dependencies on Libraries Are Killing Me 棘手的库依赖问题
(10) My Application Is All API Calls 到处都是API调用   
(11) I Don’t Understand the Code Well Enough to Change It 对代码的理解不足
(12) My Application Has No Structure 应用毫无结构可言
(13) My Test Code Is in the Way 测试代码碍手碍脚   
(14) My Project Is Not Object Oriented. How Do I Make Safe Changes? 对非面向对象的项目,如何安全地对它进行修改
(15) This Class Is Too Big and I Don’t Want It to Get Any Bigger 处理大类
(16) I’m Changing the Same Code All Over the Place 需要修改大量相同的代码
(17) I Need to Change a Monster Method and I Can’t Write Tests for It 要修改一个巨型方法,却没法为它编写测试
(18) How Do I Know That I’m Not Breaking Anything? 降低修改的风险
(19) We Feel Overwhelmed. It Isn’t Going to Get Any Better 当你感到绝望时

当你看到这些具体情形的列表,眼前是否浮现出是曾相识的经历呢?"代码修改艺术"应该说是一本实用主义的书,如果你是使用面向对象语言的程序员,那你很幸运,建议你将一本"修改代码的艺术"放在你的办工桌旁,随时翻看、思考和领悟;如果你和我一样是结构化语言的使用者,也没有关系,观其大略,品其思想,细读你兴致之所在。

以上的书中文字的中文翻译部分摘自于刘未鹏的中文译文。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats