有意思的内存监测工具,有意思的delphi6(100分)

:::::::::::::::::::::::::::::::::::::::::::::::::::::
2003-11-21 14:55:04

程序运行时间: 0 小时 0 分 38 秒。
可用地址空间: 1024 千字节
未提交部分: 976 千字节
已提交部分: 48 千字节
空闲部分: 41 千字节
已分配部分: 5 千字节
地址空间载入: 0%
全部小空闲内存块: 2 千字节
全部大空闲内存块: 38 千字节
其它未用内存块: 0 千字节
内存管理器消耗: 0 千字节

内存对象数目: 8

第二次运行时间长点,变成8了
难道D6真的有BUG吗?
 
关键是要做到以下两点:
1.找到泄点。
2.可以帮我们处理。
有这样的工具吗?
 
糊涂了,用Memory sleuth 3.01测试,无内存泄漏.
 
D7沒有,D6不知道。
 
有没有可能是你的测试程序有问题呢?
 
如果我没猜错的话,ShenNewMemMgr 应该是 CnPack 开发组成员 沈龙强 兄写的(沈兄的个人作品都用 Shen 前缀),CnMemProf 原来出自这里,难怪难怪!
刚才听程云说 DFW 上有人讨论 CnPack 盗用国外的代码,吓我一跳:)

做内存泄漏检查的工具挺多的,这里也有一个比较著名的 MemCheck,支持 D567:
http://ftp.cnvcl.org/tools/debug/memcheck263_D567.zip
MemCheck 可以通过 Map 文件定位到源代码行号,功能挺强大的。

这个目录下的东西,都是与调试测试相关的,感兴趣的朋友可以试试:
http://ftp.cnvcl.org/tools/debug/

CnPack 开发组 与月共舞
http://www.cnvcl.org
 
看到yygw的跟贴
吓偶一跳

我绝对没有说cnpack盗用国外的代码啊!!!!!
我又看了我的言论,确实没有这个意思!!!!!!

另外memcheck263_D567.zip如何用看了半天没看明白,不知哪位仁兄e文好翻译一下
A word about uses...
Since leaks are reported on end of execution (finalization of this unit), we need as many finalizations to occur
before memcheck's, so that if some memory is freed in these finalizations, it is not erroneously reported as leak. In order to
finalize MemCheck as late as possible, we use a trick to change the order of the list of finalizations.
Other memory managing products which are available (found easily on the internet) do not have this
problem because they just rely on putting the unit first in the DPR
but this is not safe without a build all.
In MemCheck we absolutely need to use two units: SysUtils and Windows.
Then, I decided in MemCheck 2.54 to use the unit Classes because I think it will lead to much simpler code.
We also use two units which we can use without risk since they dont have a finalization: Math and SyncObjs.
An analysis of the uses clauses of these five units shows that in fact MemCheck uses indirectly the following units:
Math, Classes, Typinfo, Consts, Variants, VaRUtils, SysUtils, ActiveX, Messages, SysConst, Windows, SyncObjs, System, SysInit and Types.
Of these, only Classes, Variants, System and SysUtils have a finalization section. I checked and it is not possible to have a leak
reported by MemCheck which is not correct because the memory would have been freed by one of these finalizations.
In the procedure ChangeFinalizationsOrder I make sure that only these four units are finalized after MemCheck (I could have decided for
the fifteen, but this would be more work, and I know it is useless).
 
这个ShenNewMemMgr检测工具是我写的,经过我的测试,发现只有在D5下工作良好,在D7下基本正常工作,在D6下会出现误报,原因跟上面的这段英文有关,我简单的翻译一下这段文字(我英文也不好,说说大概的意思):

因为内存检测只有在程序执行完成时才能报告,所以需要把MemCheck单元的终止过程放在其他的单元的终止过程之后,一些其他的内存管理工具解决这个问题的方法是把自己放在dpr文件的第一个uses单元,但是这个方法对于没有Build all的单元是不安全的(注:有很多的单元在编译的时候直接通过DCU文件编译的,一则可以加快编译速度,二则有很多单元并没有提供源代码),而MemCheck是通过一个小技巧改变了单元的终止过程在终止过程列表中的位置实现的。
后面的就是说他对一些单元的分析结果了:)

我的这个单元的代码基本上是按照Delphi 5技术手册上的代码改写的,所以的确是有上述的原因,但是我觉得关键是替代的内存管理器的生命周期要贯彻于整个程序的生命周期,这样才能保证正确的检测,不过这对于简单的替代Delphi的内存管理器的单元来说似乎不大可能实现,因为Delphi就内置了System,SysInit等几个单元的;所以我觉得只有那种作为宿主而存在的程序才有可能做到完全的内存检测,不过那就不是轻量级的检测工具了,而且也有它自己的限制(比如说调试版本的发布就有不方便了)。
 
调用DLL中的窗体,free后肯定有4K或8K的内存泄漏!D6D7都一样,一个很明显的Delphi大BUG!!!!!!!
 
其实,这都没什么,最关键的是:
当你的程序长时间运行时,是否有内存使用不断增加的情况,
如果有,则查找原因,予以避免,
如果不能避免,则程序需要定时重新启动
 
调用Dll的内存泄漏的确是有的,出问题的代码是Forms单元的MakeObjectInstance和FreeObjectInstance,每次应该是4k的泄漏,网上有相关的解决代码的,我以前在大富翁曾经在一个跟贴中贴过的。

顺便: 本人是CnPack的成员,所以CnPack的内存检测单元就是ShenNewMemMgr。也希望大家能够关注CnPack,为中国的软件发展贡献力量:)
 
yygw:
>>>>MemCheck 可以通过 Map 文件定位到源代码行号,功能挺强大的。

怎么实现呀。不知道呢。指点一下。
 
to:shenloqi,
同意!

用 MemProof 每次都有 4096 个字节释放不了。
这个是 Delphi 的问题。MemProof 也不把它做为是错误!
 
内存泄漏?那D6的程序就成了shell了?嘿嘿...[:D]
 

Similar threads

回复
0
查看
514
不得闲
D
回复
0
查看
672
DelphiTeacher的专栏
D
D
回复
0
查看
684
DelphiTeacher的专栏
D
D
回复
0
查看
700
DelphiTeacher的专栏
D
顶部