这是一个创建于 4107 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
ChangeTheWorld 2014 年 11 月 5 日
被迫重启……先加一个24天自动重启的脚本再说
|
 |
2
hjc4869 2014 年 11 月 5 日
这种级别的大项目不做好unit test，不在每个unit test上考虑可能产生内存泄漏的地方，就是作死。
|
 |
3
zlbruce 2014 年 11 月 5 日
可以用 valgrind 试试
|
 |
4
shawngao 2014 年 11 月 5 日
讲下以前公司的做法：
一般是先回退版本，测试找到无内存泄漏的commit，以这个commit新建一个checkbranch，让每个开发人员去diff自己模块的最新版本与这个checkbranch，检查自己修改的代码。 开发人员如果觉得没问题，则将diff提交到checkbranch，由PM编译版本并测试。 通过后进行下一个。 |
 |
5
openroc 2014 年 11 月 5 日
之前在windows上遇到过，泄露handle的，一次就是4个字节，由于server连续运行，时间长了，就。。。。。 哈哈
|
 |
6
min 2014 年 11 月 5 日  1
一天只漏这么一点点，随便插一条内存可以多跑一个月了
不够再加 |
 |
7
yanwen 2014 年 11 月 5 日
田春 是伞哥么？
|
|
8
yanwen 2014 年 11 月 5 日
擦。。一看 还真是伞哥。。。
|
 |
9
wdlth 2014 年 11 月 5 日
写了这么多代码都不做内存泄露检测的么？
|
 |
11
LazyZhu 2014 年 11 月 5 日
内存dump后看看？
|
 |
12
zhangdawei 2014 年 11 月 5 日
@vivyli 我们公司也是这么干的，代码历史悠久，别的办法不多。
|
 |
14
akira 2014 年 11 月 5 日 1
对内存申请/释放函数做钩子 日志记录下调用入口以及申请的大小以及返回内存地址
跑上一段时间后日志处理下应该就能知道大概是那些调用点出了问题 |
 |
15
stormslowly 2014 年 11 月 5 日
14正解 很多单元测试框架就搞的。。
|
 |
16
cvrock 2014 年 11 月 5 日
啥平台？在win下只要开了全页堆windbg扫两眼就能秒杀了。
|
 |
17
nsa 2014 年 11 月 5 日 via iPad
日志，日志，还是日志
|
 |
19
yuezhimsolo 2014 年 11 月 5 日
总结：应急 - 先加一个24天自动重启的脚本；思路 - 日志；过程 - 回退版本，测试找到无内存泄漏的commit，以这个commit新建一个checkbranch，让每个开发人员去diff自己模块的最新版本与这个checkbranch，检查自己修改的代码。
关键话：不在每个unit test上考虑可能产生内存泄漏的地方，就是作死。 |
 |
21
tabris17 2014 年 11 月 5 日
这道题目的关键在于“无法重现这个问题”。否则很好解决，无论是倒退版本做code review还是调试或dump内存。
|
|
22
tabris17 2014 年 11 月 5 日
另外不是有静态代码检查工具的嘛，不是CPPer，具体不清楚
|
Select Language