BUG就是BUG，BUG不是灵异

最近我们团队在做一个项目，发布测试版本时发现，在老大的WIN7 X64上播放一个节目时，不管如何，内存都会快速上涨，而我的WIN7 X64上偶尔会碰到内存上涨，而其他组员全是XP，但都没有发现上涨的情况。而且程序退出时，内存是正常释放的。这就说明不是一般的内存泄漏，而是在某一时刻应该释放的内存没有释放或说不该出现的内存出现了。

鉴于内存上涨的快速，我们首先想到可能是分配的大数据块没有在合适的时间释放。经过打印信息，不是！

我们又把所有涉及通信的消息都做了统计，显示都正常

.................

就这样一边抓紧完成功能，一边在想为什么会这样：一台WIN7必现（我们没法在这台机器上调试）；一台偶尔出现，但感觉重新编译就好了；其他XP都不会出现...

我们自己NEW的内存又都是在我们想释放的时候都正常释放了。但为什么内存还会上涨？为什么在不同的机器上表现还不一样？

难道是软件环境不同？有杀毒软件？new,delete被hook了？windows库兼容有问题？是用到的第三方库在WIN7上有BUG？...........

事实证明我想多了，很多时候，BUG没有这么多传奇色彩，它很普通，很乌龙~~

经过很曲折的调试，最后用排除法，终于确定是专门写日志的DLL有问题！在配置文件里配置成日志关闭，此时日志模块只接受日志保存到队列里，而不清除（清除只在从队列里取出记录，写到文件里时才清除）。而我们为了确保播放过程中，如果碰到问题能追踪解决，一般都会开日志。测试部门也一样，为了能出现问题时给我们日志，所以也是要开日志的。而我发给老大和测试部门的版本默认是不打开日志的，因为日志数量实在不少。

为什么在排查内存上涨的过程中，没有首先把日志模块排除掉？

可能是日志模块只是这个项目中的附属模块，不会在正式发布时发布，所以无意中忽略了它的存在。

其实我也想到了排除日志，所以把日志关闭掉了。但我一厢情愿的认为只要在配置文件里设置open=0，就不会再写日志了。而且在写日志模块代码时，我也明确和组员说了，只要open=0，就不接收日志记录了。但因为太忙，我没有追踪这个功能，浅意识里也认为这上功能简单，完成肯定没问题。谁想到啊，open=0，只是不写了，还接收放到队列里，累积起来了....

不一定要自己明确NEW的内存，才是内存...

先入为主是魔障！BUG就是BUG！BUG没有灵异事件...