delphi - 寻找 EOutOfResources

Question

题:

是否有一种简单的方法可以获取正在运行的应用程序中泄漏的资源类型列表？ 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 拉伸(stretch) + tmetafile，但在保存到磁盘时出现此错误(TFileStream)句柄可能是真的累。然而，在同一个流中，TMetafile 也被保存到流中，这是后来的应用程序不再有的东西，它们可以运行数月。

- - - - - - - - - - 更新

我已经搜索，搜索，搜索，并设法在体外重现问题两三次。当 memusage 为 +/- 256MB(系统有 2GB)，用户对象 200，gdi 对象 500，没有一个文件比预期打开的文件多时，就会出现问题。

这并不异常(exception)。我确实注意到我泄漏了少量句柄，可能是由于重新设置帧(VCL 中的某些内容似乎泄漏了 HPalette)，但我怀疑核心原因是另一个问题。我重用 TMetafile，并在两者之间清除它。我认为清除图元文件并没有真正(总是？)调整资源大小，最终整个 tmetafile 池中的每个图元文件都处于最大大小，并且有 20-40+ tmetafiles(每个可以是几个 100ks)这将击中桌面堆限制。

这是理论上的，但我会尝试通过将客户的桌面限制设置为 10MB 来验证这一点，但是如果这有任何改变，我需要几周时间才能确认。这个理论也证实了为什么这台机器很特别(这台机器自然平均有稍微大一点的图元文件)。偶尔在池中释放和重新创建 tmetafile 也可能有所帮助。

幸运的是，所有这些问题(tmetafile 和 reparenting)都已经在新一代应用程序中设计出来了。

由于特殊情况(以及我的测试窗口非常有限的事实)，这将需要一段时间，但我现在决定接受桌面堆作为示例(尽管 GDILeaks 的东西也有些用处)。

另一件事，审计揭示了线程中 GDI 类型的使用(尽管只将 tmetafiles(未使用或以其他方式连接)保存到流中。

------------- 更新2。

增加桌面限制似乎只是稍微增加了问题发生的时间。

不幸的是，我将无法进一步跟进，因为这些机器已更新到没有问题的较新版本的框架。

总之，我只能说明从旧框架到新框架的三个核心修改:

我不再通过重新设置框架来更改屏幕。我现在使用我隐藏和显示的表单。我改变了这一点，因为我也有非常罕见的崩溃或异常(可以被点击)。崩溃都是在操作 GUI 时发生的，不像主要问题那样自发地发生

发生崩溃的例程处理 TMetafile。 TMetafile 已经被设计出来，并被一个更简单的自己制作的格式所取代。 (基本上是带有 Opengl 顶点的数组)

不再使用 tbitmap 进行绘图，而是使用 OpenGL。

当然它也可能是别的东西，在上面部分的重写中得到了改变，修复了一些非常讨厌的细节错误。这一定是非常糟糕的，因为我尽可能多地分析了上述系统。

2012 年 11 月更新 经过一些私有(private)邮件讨论:回想起来，下一步应该是向元文件对象添加一个计数器，并且每隔 x * 1000 次左右简单地重新实例化它们，看看是否有任何改变。如果您有类似的问题，请尝试查看是否可以定期销毁和重新初始化动态分配的长生命周期资源。

Answer 1

如果它们是 GDI 句柄泄漏，您可以查看 MSDN Magazine January 2003使用工具 GDILeaks .其他工具是 GDIObj或 GDIView .另见 here .

EOutOfResources 的另一个来源可能是 Desktop Heap已满。我在繁忙的大屏幕终端服务器上遇到过这个问题。

如果您泄漏了大量文件句柄，您可以查看进程资源管理器并查看进程的打开文件句柄并查看任何异常。或者使用带有 !htrace 的 WinDbg命令。