田春出的这道内存泄露题你们会怎么做？

被迫重启……先加一个24天自动重启的脚本再说

这种级别的大项目不做好unit test，不在每个unit test上考虑可能产生内存泄漏的地方，就是作死。

可以用 valgrind 试试

讲下以前公司的做法：

一般是先回退版本，测试找到无内存泄漏的commit，以这个commit新建一个checkbranch，让每个开发人员去diff自己模块的最新版本与这个checkbranch，检查自己修改的代码。

开发人员如果觉得没问题，则将diff提交到checkbranch，由PM编译版本并测试。
通过后进行下一个。

之前在windows上遇到过，泄露handle的，一次就是4个字节，由于server连续运行，时间长了，就。。。。。 哈哈

一天只漏这么一点点，随便插一条内存可以多跑一个月了
不够再加

田春 是伞哥么？

擦。。一看 还真是伞哥。。。

写了这么多代码都不做内存泄露检测的么？

@shawngao 感觉这样周期很长，因为说是无法重现，每次rollback都要用客户的环境做测试，一来一回客户就疯掉了。。

内存dump后看看？

@vivyli 我们公司也是这么干的，代码历史悠久，别的办法不多。

@wdlth @shawngao 印象中他说过是100W行lisp转成300W行c代码再编译，而且是个很久的项目，这个级别很难吧

对内存申请/释放函数做钩子 日志记录下调用入口以及申请的大小以及返回内存地址
跑上一段时间后日志处理下应该就能知道大概是那些调用点出了问题

14正解 很多单元测试框架就搞的。。

啥平台？在win下只要开了全页堆windbg扫两眼就能秒杀了。

日志，日志，还是日志

@shawngao 无法重现这个问题

总结：应急 - 先加一个24天自动重启的脚本；思路 - 日志；过程 - 回退版本，测试找到无内存泄漏的commit，以这个commit新建一个checkbranch，让每个开发人员去diff自己模块的最新版本与这个checkbranch，检查自己修改的代码。
关键话：不在每个unit test上考虑可能产生内存泄漏的地方，就是作死。

@akira 这个才是正解