Chinaunix首页 | 论坛 | 博客
  • 博客访问: 482959
  • 博文数量: 78
  • 博客积分: 995
  • 博客等级: 准尉
  • 技术积分: 1462
  • 用 户 组: 普通用户
  • 注册时间: 2011-11-15 20:22
个人简介

技术中沉思的时候最快乐,问题得到完美解决的时候最有成就感!

文章分类

全部博文(78)

文章存档

2013年(39)

2012年(37)

2011年(2)

分类: C/C++

2012-07-06 19:30:08

一个比较复杂的svr程序,修改了一个比较小的地方;因为复杂,所以保险起见,做了单元测试,
做了压力测试,都没问题,信心满满的放到运营环境中去;跑了半小时,突然core了2个节点,gdb 一看,
core 在了框架里面,而且core的地方都不一样;重启后,怀着侥幸的心理,再跑了半小时,又挂了一个
节点;不行了,只能回滚;切换到旧的版本,一切正常;

分析现场,查bug
gdb了生成的几个core现场,查看了保留的svr log,没发现什么有价值的信息;心理没底了,就改
了一个非常小的地方,不过几行代码,竟然core的莫名其妙;根据 gdb 显示的堆栈信息,基本都在用了很
久的框架里面或者一些c++的库里面,可以确定的是:内存应该是之前某时被写乱了,后面的core和堆栈基本
没有了什么意义;

第一次尝试解决:
直觉是:编译哪里出问题了,因为以前这种现象以前也出现过,基本都是因为模块太多,但编译开
关不一致造成的;查了下makefile中涉及到的所有的lib库,跑过去一个一个 make clean,然后重新 make
build,然后非常细心的查看各个编译开关,确保编译是一致的;最后make出svr程序,然后跑单元测试,压
力测试,都通过;然后再次放到运营环境中去,然后祈求手机不要再突然叮咚(监控有手机报警)报警,半
小时过了,一个小时过了,大概稳定了;于是忙其他事去,“叮咚”,我了个去,悲催的事情还是发生了,
又 core 了;悲剧了,gdb core 文件,还是乱七八糟的堆栈,没任何意义;

第二次尝试:
运营环境不敢试了,没找到确定问题之前,不能再拿运营环境做我的小白鼠了;于是,把希望转移
到了压测环境,希望在测试环境中能重新这一bug,然后不停的测试,改压力,改测试数据;然后祈祷core
出现;悲催的是两个小时下来,就是 core 不掉啊;...

当心理没有任何底的时候,有点迷茫的时候,暂时的放一放吧,于是不去搞了;晚上回到家里,洗
澡的时候,又想起了这件事,觉得内存问题引起的core,想从日志或者core文件等现场入手估计比较难;
内存问题,哦,想起了 valgrind,或许可以查处问题来;嗯,突然有种立马跑一跑 valgrind,但没环境,
于是睡觉,等第二天到公司试试;

第二天的尝试:
首先,还是把svn上的代码全部拉下来,然后替换了开发机上的代码,全部重新编译了一次;中间
发现了一些小问题,有些 makefile 竟然没上传到 svn 上去,然后开发机的 makefile 被svn的旧文件覆盖
了,悲剧,又手动去改 makefile,然后再把新的 makefile 传到 svn 上去;

编译了后,放到压测环境,运行压力测试,几分钟下来,竟然 core 了!!再跑一遍,几分钟下来,
又 core 了,今天的 core 来的特别容易;现象和运营环境中一模一样;呃,终于重现了,能重现就好,心
里有些底了;架起 valgrind,tmd 的,特别慢,慢的离谱;跑了十几分钟,都没 core,但发现 valgrind 
输出的诊断日志里面一堆一堆的报警:大部分都是:Conditional jump or move depends on uninitialised
value(s);呃,申请的内存有很多地方都没有 bzero,直接在上面做文章,感觉应该不会有什么问题(
直这样用的),但既然有问题,还是修正下吧,于是加了 bzero 初始化;
几分钟搞定修改和编译,然后再压,几分钟下来,core 了,然后 valgrind 的输出是:
访问一处错误的4个字节(大概意思是说这4个字节既不是malloc分配的内存,也不是栈内存),然后
根据提示出问题的代码地方;汗,竟然是5月份那时候框架中加的一个统计类,这个类有一个做为统计
用的数组,数组越界了,终于明白了!!数组越界,写到其他内存地址上去了,什么结果都可能发生...

修正了这个数组越界bug,重编,再跑;信心满满,没什么问题了;果然,ok了,直接替换到了运营
环境去;安静的跑,心理很是有底!!
阅读(3534) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~