题:
有一种简单的方法可以获得正在运行的应用程序中泄漏的资源类型列表吗？IOW通过连接到应用程序？
我知道memproof可以做到这一点,但它减速太多,应用程序甚至不会持续一分钟.大多数任务管理员喜欢可以显示数字,但不能显示类型.
检查本身是灾难性的(停止应用程序进程)不是问题,因为我可以检查taskmgr我是否接近(或者至少我希望)
关于资源泄漏狩猎(所以不是记忆)的任何其他见解也受到欢迎.
背景:
我有一个Delphi 7/2006/2009应用程序(编译所有三个),大约几周后它开始表现得很有趣.但是,仅在其运行的一个地方,在其他几个系统上运行直到电源耗尽.
我试图输入一些调试代码来缩小问题范围.并发现EOutofResources的例外是保存文件.(文件保存每天可以发生数千次).
我试图推断出内存泄漏(使用fastmm),但由于数据流非常高(从千兆工业相机的60MByte/s),我只能排除"蠕动"内存泄漏与fastmm,而不是快速闪存的内存泄漏记忆在它发生的时间.如果出现问题,应用程序会在半分钟内填满内存.
主要嫌疑人是文件句柄,以某种方式留下了一些错误和TMetafiles(流式传输到这些文件).小嫌犯是VST,popupmenu和tframes
更新:
另一个可能的提示:它与D7一起运行了两年,现在问题出在Turbo Explorer(我用于稳定的项目未转换为D2009).
Paul-Jan:由于它每周只发生一次(并且可能在晚上发生),因此信息获取速度很慢.这就是为什么我问这个问题,需要在我周四的时候把东西组合起来.简而言之:不,我不知道100%肯定.我打算带上整个Systemtools集合,看看我是否能找到一些东西(因为它会运行几天).我也有机会看到打开的文件.(也许应该尝试找一些mingw lsof并安排它)
但该应用程序看到很少的GUI动作(它是一个机器视觉检测应用程序),除了屏幕刷新+/- 15/s,这是tbitmap stretchdraw + tmetafile,但我得到这个错误保存到磁盘(TFileStream)句柄可能真的累.然而,在同一个流中,TMetafile也可以保存,后来的应用程序不再拥有它,它们可以运行数月.
-------------------更新
我搜索,搜索和搜索,并设法在体外重现问题两三次.当memusage为+/- 256MB(系统有2GB),用户对象200,gdi对象500,而不是一个比预期更开放的文件时,会出现问题.
这不是特别的.我注意到我泄漏了少量的手柄,可能是由于重新渲染帧(VCL中的某些东西似乎泄漏了HPalette的),但我怀疑核心原因是另一个问题.我重用了TMetafile,然后将它清除.我认为清除元文件并不是真的(总是？)调整资源大小,最终整个tmetafile池中的每个元文件都是最大的,并且有20-40 + tmetafiles(每个可以是几个100k),这将会打到桌面堆限制.
这是理论,但我会尝试通过将客户端的桌面限制设置为10MB来验证这一点,但是如果这有任何改变,我将在几周前确认.这个理论也证实了为什么这台机器是特殊的(这台机器平均可能有一个稍微大一点的元文件).偶尔在池中释放和重新创建tmeta文件也可能有所帮助.
幸运的是,所有这些问题(tmetafile和reparenting)都已在新一代应用程序中设计出来.
由于特殊情况(以及我的测试窗口非常有限),这将是一段时间,但我现在决定接受桌面堆作为一个例子(虽然GDILeaks的东西也有些用处).
另一件事是审计揭示了线程中的GDI类型用法(尽管只保存tmetafiles(未使用或以其他方式连接)到流.
-------------更新2.
增加桌面限制似乎只会略微增加问题发生的时间.
不幸的是,我将无法进一步跟进,因为机器已更新为没有问题的框架的更新版本.
总之,我只能说明从旧框架到新框架的三个核心修改:
当然它也可能是其他东西,在重写上述部分时发生了变化,修复了一些非常讨厌的细节错误.它必须是一个非常糟糕的,因为我尽可能多地分析了上述系统.
在一些私人邮件讨论之后更新了nov 2012:回想起来,下一步将是为元文件对象添加一个计数器,并且每次x*1000使用左右只是重新实例化它们,并查看是否有任何改变.如果您遇到类似问题,请尝试查看是否可以在某种程度上定期销毁和重新初始化动态分配的长生存资源.