关于内存越界的问题

      在上家公司的时候，服务器出了一个很郁闷的问题，做压力测试的时候，一旦人数上到1000多的时候，会不定时的出现崩溃现象，虽然崩溃的地方相同，但是和崩溃的起始点已经相差很远，gdb的断点基本上用处不大。

      后来在网上查了许多资料，基本上定位是内存地址越界引起，只是不知道具体的越界地点。

      当时我做的第一个措施是把所有的sprintf、memcpy，strcpy等相关容易出现内存地址越界的函数都检查了一遍，都加了防御代码，不过遗憾的是问题不是出在这些地方。崩溃问题依旧。

      分析代码尝试解决失败，只能依赖工具，尝试了valgrind等几乎所有linux下的内存检查工具，但是这些工具都有一个致命的缺陷，我们的服务器程序太臃肿了，跑起来非常卡，连正常启动加载运行时10秒就能完成的任务，用这些工具都需要20分钟以上。更不用说使用压测工具跑机器人了。我尝试了一周左右，一直未能找到问题，后来觉得这种方案不太靠谱，就放弃了，一直使用分析代码的方式。直到离职前也未能解决，比较遗憾。

       前不久，听说上家公司的技术总监解决了这个问题，打听了一下，原来出现问题的地方非常简单，如下：

//关闭战斗
g_fightMgr->closeFight(m_fight);
m_fight = NULL;

      我们的游戏是回合制，战斗后台使用的是状态机来实现的，上面的代码是最后一个状态中关闭战斗的语句，在closeFight里面会将所有的状态delete掉，包括这段代码所在的状态，然后后面的给m_fight赋值为NULL就造成了非法写内存。解决的方案把最后一句删掉或者放到closeFight前面即可。

      问了一下如何发现这个问题，其实也是不停的跑valgrind，跑了一个月，跑到吐最后才发现了问题。

      通过这件事情，我总结一下，在解决linux崩溃这些疑难杂症上，必须分析代码+使用工具，代码分析是我的强项，但是使用工具这方面我还有待加强，而且不能急躁，要多一点耐心，多一点坚持，问题一定能解决。我缺乏的就是耐心好持久。最后我还是比较欣慰，我离开上家公司唯一的遗憾总算是解决了，祝以前的小伙伴们好运！也为自己提了个醒，以后遇到类似的问题要做到更好。谨以此记。