12

问题：

有没有一种简单的方法来获取正在运行的应用程序中泄漏的资源类型列表？IOW 通过连接到应用程序？

我知道 memproof 可以做到，但它的速度非常慢，以至于应用程序甚至不会持续一分钟。大多数taskmanager喜欢可以显示数字，但不能显示类型。

检查本身是灾难性的（停止应用程序进程）不是问题，因为如果我接近（或者至少我希望），我可以使用 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（每个可以是几个 100ks）这将打到桌面堆限制。

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

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

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

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

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

增加桌面限制似乎只会略微增加问题发生的时间。

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

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

  • 我不再通过重新设置框架来更改屏幕。我现在使用我隐藏和显示的表单。我改变了这一点，因为我也因此而发生了非常罕见的崩溃或异常（可以点击离开）。崩溃都是在操作 GUI 时发生的，不像主要问题那样自发
  • 发生崩溃的例程处理 TMetafile。TMetafile 已被设计出来，取而代之的是一种更简单的自制格式。（基本上是带有 Opengl 顶点的数组）
  • tbitmap 不再使用 tmetafile 覆盖在其上绘制，而是使用 OpenGL 进行绘制。

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

在一些私人邮件讨论后于2012 年 11 月更新：回想起来，下一步将是向元文件对象添加一个计数器，并在每 x * 1000 次左右使用时简单地重新实例化它们，看看这是否会改变任何东西。如果您有类似的问题，请尝试查看是否可以定期销毁和重新初始化动态分配的长寿命资源。

4

8 回答 8

12

该错误具有误导性的可能性很小。如果 VCL无法获得窗口的 DC，则VCL 天真地报告EOutOfResources （请参阅Controls.pas中的TWinControl.GetDeviceContext）。

我说“天真”是因为GetDC()可能返回 NULL 句柄和 VCL 应该报告操作系统错误的其他原因，而不是假定资源不足的情况（需要进行 Windows 版本检查才能可靠地实现这一点，但 VCL 也可以而且应该接受）。

由于窗口句柄变得无效，我遇到了EOutOfResources错误。一旦我发现了真正的问题，找到原因并修复它很简单，但是我浪费了很多很多时间来寻找不存在的资源泄漏。

如果可能的话，我会检查导致此异常的堆栈跟踪 - 如果它来自TWinControl.GetDeviceContext那么问题可能不是你想的那样（当然不可能说出它可能是什么，但消除不可能总是第一个朝着发现解决方案的方向前进，无论多么不可能）。

于 2010-02-02T02:58:19.243 回答
6

如果它们是 GDI 句柄泄漏，您可以查看使用GDILeaks工具的MSDN 杂志 2003 年 1 月。其他工具是GDIObj或GDIView。也见这里。

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

如果您泄漏了很多文件句柄，您可以查看 Process Explorer 并查看进程的打开文件句柄并查看任何异常。或者使用带有!htrace命令的 WinDbg。

于 2010-02-02T09:15:27.863 回答
3

我以前遇到过这个问题。据我所知，Delphi 可能会在 Windows API 返回 ERROR_NOT_ENOUGH_MEMORY 的任何时候抛出 EOutOfResources，并且（正如这里讨论的其他答案）Windows 可能会在各种情况下返回 ERROR_NOT_ENOUGH_MEMORY。

在我的情况下，EOutOfResources 是由 TBitmap 引起的 - 特别是 TBitmap 对CreateCompatibleBitmap的调用，它使用它的默认 PixelFormat 的 pfDevice。显然，即使您的系统有足够的内存和大量的 GDI 资源，Windows 也可能会在系统范围内对设备相关位图可用的内存实施相当严格的限制（参见，例如，本讨论）。（这些系统范围的限制显然是因为 Windows 可能会在视频卡的内存中分配与设备相关的位图。）

解决方案是简单地使用与设备无关的位图 (DIB)（尽管这些位图可能无法提供相当好的性能）。要在 Delphi 中执行此操作，请将 TBitmap.PixelFormat 设置为 pfDevice 以外的任何内容。 这篇知识库文章介绍了如何为设备选择最佳 DIB 格式，尽管我通常只使用 pf32Bit 而不是尝试确定显示应用程序的每个监视器的最佳格式。

于 2013-08-08T16:58:42.300 回答
2

大多数时候我看到EOutOfResources，这是某种句柄泄漏。

您是否尝试过MadExcept 之类的方法？

——杰伦

于 2010-02-01T22:45:03.810 回答
2

“我尝试输入一些调试代码来缩小问题范围。发现异常是文件保存时的 EOutofResources。（文件保存每天可能发生数千次）。”

我在这里在黑暗中拍摄，但是您是否正在使用 Windows API (GetTempFileName) 创建一个临时文件并且您正在破坏一些文件系统索引或忘记关闭文件句柄？

无论哪种方式，我都同意您关于这是文件句柄问题的假设。考虑到您的症状和诊断，这似乎是最有可能发生的事情。

于 2010-02-02T00:36:02.480 回答
0

还尝试使用 SysInternals 的 Process Explorer 检查应用程序的句柄计数。处理泄漏可能非常危险，并且随着时间的推移它们会慢慢形成。

于 2010-02-02T06:32:51.070 回答
0

我目前遇到了这个问题，在我自己的代码中显然没有泄漏任何句柄的软件中，所以如果有泄漏，它们可能发生在组件的源代码或 VCL 源代码本身中。

句柄计数和 GDI 和用户对象计数没有增加，也没有创建任何东西。Deltic 的回答显示了消息是一种红鲱鱼的极端情况，艾伦建议即使是文件写入也可能导致此错误。

到目前为止，我发现寻找它们的最佳策略是使用 JCL JCLDEBUG 堆栈回溯或 MadExcept 中的异常报告保存功能来生成上下文信息以找出实际失败的原因。

其次，AQTime 包含许多可以帮助您的工具，包括资源分析器，它可以保持创建资源的代码所在位置、调用方式以及句柄总数之间的链接。它可以在 MID RUN 中抓取结果，因此它不仅限于在您退出后检测未释放的资源。因此，运行 AQTime，在运行中进行一次结果捕获，等待几个小时，然后再次捕获，您应该有两个时间点来比较句柄计数。以防万一这是显而易见的事情。但正如 Deltics 明智地指出的那样，这个异常类是在它可能不应该出现的情况下引发的。

于 2010-07-23T16:14:31.087 回答
0

我花了今天所有的时间来追查这个问题。我发现很多有用的资源将我指向 GDI 的方向，事实上我正在使用 GDI+ 通过 timer/invalidate/onpaint（在单独的线程中执行的动画）直接在主窗体上生成高速动画。我还有一个这种形式的面板，其中包含一些动态创建的控件，供用户更改动画。

这是非常随机和自发的。它不会破坏我的代码中的任何地方，并且当出现错误对话框时，主窗体上的动画将继续工作。在某一时刻，其中两个错误同时出现（而不是顺序出现）。

我仔细观察了我的代码，并确保我没有泄露任何与 GDI 相关的句柄。事实上，根据任务管理器，我的整个应用程序往往保留少于 300 个句柄。无论如何，这个错误会随机弹出。它总是与最简单的 UI 相关操作相对应，例如将鼠标移动到标准 VCL 控件上。

解决方案

我相信我已经通过将逻辑更改为在自定义控件中执行绘图来解决它，而不是像以前那样直接到主窗体。我认为我在共享其他控件的同一个表单画布上快速绘图的事实，不知何故它们干扰了。现在它有自己的专用画布可以绘制，它似乎已经完美修复了。

也就是说，至少要进行大约 1 小时的剧烈测试。

动画工作没有错误

[手指交叉]

于 2019-09-23T00:50:46.193 回答