一个比较复杂的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了，直接替换到了运营
环境去；安静的跑，心理很是有底!!
阅读(3890) | 评论(0) | 转发(0) |
