寻找EOutOfResources [英] Hunting down EOutOfResources
问题描述
问题：
有没有一种简单的方法来获取正在运行的应用程序中泄露的资源的类型列表？ IOW通过连接到应用程序？
我知道memproof可以做到这一点，但它减慢了很多，以至于应用程序甚至不会持续一分钟。大多数taskmanager喜欢可以显示数字，但不能显示类型。
检查本身是灾难性的（停止应用程序进程）并不是问题，因为我可以检查有一个taskmgr，如果我越来越近（或至少我希望）
任何其他洞察资源泄漏搜索（所以不是内存）也是欢迎。 >
背景：
我有一个Delphi 7/2006/2009应用程序（与所有三个编译），之后约几个星期开始表现有趣。但是，只有在其运行的其中一个地方，在其他几个系统上才能运行，直到电源熄灭。
我试图放入一些调试代码来缩小问题下降。并发现异常是EOutofResources保存的一个文件。 （文件保存每天可能会发生数千次）。
我已经尝试解决内存泄漏（使用fastmm），但由于数据流相当高（60MByte / s从吉比特工业相机的），我只能排除爬行的内存泄漏与fastmm，而不是快速闪烁的内存泄漏，在发生的时候耗尽内存。如果出现问题，应用程序会在半分钟内填满内存。
主要嫌疑人是以某种方式留下某些错误的文件句柄和TMetafiles（被流传到这些文件）。次要犯罪嫌疑人是VST，弹出菜单和tframe
更新：
另一个可能的提示：与D7，现在的问题是与Turbo Explorer（我用于稳定的项目没有转换为D2009）。
保罗 - 扬：因为它只发生一周一次（晚上可能发生），信息采集缓慢。这是为什么我问这个问题，需要结合的东西，当我在那里星期四。总之：不，我不知道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（每个可以有几百个），这将打到桌面堆极限。
这是理论，但我会尝试通过将桌面限制设置为10MB的客户端来验证，但是如果这样更改，我将在几周前确认任何事情这个理论也证实了为什么这台机器是特别的（这个机器有可能自然地平均有更大的元文件）。偶尔在游泳池中释放和重建一个tmetafile也可能有帮助。
幸运的是，所有这些问题（包括tmetafile和reparenting）都已经在新一代应用程序中设计出来了。
由于特殊情况（事实上我的测试窗口非常有限），这将是一段时间，但我决定接受桌面堆现在的一个例子（虽然GDILeaks的东西也是有用的）。
另一件事情是审计透露了一个线程中的GDI类型使用（尽管只保存tmetafiles没有使用或连接）流。
-------------更新2。
增加桌面限制似乎稍微增加了问题发生的时间。
不幸的是，我将无法跟进这更进一步，因为机器被更新到没有问题的更新版本的框架。
总而言之，我只能说明从旧到新框架的三个核心修改：
- 我不再通过reparenting来更改屏幕框架。我现在正在处理我隐藏和展示的表单。我改变了这一点，因为我也有非常罕见的崩溃或例外（可以点击）。崩溃都是在操作GUI的时候，而不是自发地像主要的问题。
- 事件发生的例程处理TMetafile。 TMetafile已经被设计出来，并被更简单的自己制作的格式所替代。 （基本上是Opengl顶点的数组）
- 图形不再与tbitmap一起使用，而是使用了一个tmetafile覆盖，而不是使用OpenGL。
当然这可能是别的东西，改写了上述部分的改写，修复了一些非常讨厌的细节错误。这将是一个非常糟糕的，因为我尽可能分析了上述系统。
更新nov 2012 之后，一些私人邮件讨论：回想起来，下一步将是添加一个对象的元文件对象，只需要重新启动它们每x * 1000的使用等等，看看是否改变了任何东西。如果您有类似的问题，请尝试看看您是否可以有时间地摧毁并重新初始化动态分配的长寿命资源。</ p>
如果他们是GDI处理泄漏，你可以看一下 MSDN Magazine 2003年1月，使用工具 GDILeaks 。其他工具是 GDIObj 或 GDIView 。另请参阅 here 。
另一个EOutOfResources的来源可能是桌面堆已满。在具有大屏幕的繁忙的终端服务器上，我遇到了这个问题。
如果有很多文件句柄泄漏，您可以查看Process Explorer，并查看过程的打开文件句柄，并查看任何普通的。或者使用WinDbg与！htrace 命令。
Question:
Is there an easy way to get a list of types of resources that leak in a running application? IOW by connecting to an application ?
I know memproof can do it, but it slows down so much that the application won't even last a minute. Most taskmanager likes can show the number, but not the type.
It is not a problem that the check itself is catastrophic (halts the app process), since I can check with a taskmgr if I'm getting close (or at least I hope)
Any other insights on resource leak hunting (so not memory) is also welcomed.
Background:
I've an Delphi 7/2006/2009 app (compiles with all three) and after about a few week it starts acting funny. However only on one of the places it runs, on several other systems it runs till the power goes out.
I've tried to put in some debug code to narrow the problem down. and found out that the exception is EOutofResources on a save of a file. (the file save can happen thousands of times a day).
I have tried to reason out memory leaks (with fastmm), but since the dataflow is quite high (60MByte/s from gigabit industrial camera's), I can only rule out "creeping" memory leaks with fastmm, not quick flashes of memoryleaks that exhaust memory around the time it happens. If something goes wrong, the app fills memory in under half a minute.,
Main suspects are filehandles that are somehow left on some error and TMetafiles (which are streamed to these files). Minor suspects are VST, popupmenu and tframes
Updates:
Another possible tip: It ran fine for two years with D7, and now the problems are with Turbo Explorer (which I use for stable projects not converted to D2009 ).
Paul-Jan: Since it only happens once a week (and that can happen at night), information acquisition is slow. Which is why I ask this question, need to combine stuff for when I'm there thursday. In short: no I don't know 100% sure. I intend to bring the entire Systemtools collection to see if I can find something (because then it will be running for days). There is also a chance that I see open files. (maybe should try to find some mingw lsof and schedule it)
But the app sees very little GUI action (it is an machine vision inspection app), except screen refresh +/- 15/s which is tbitmap stretchdraw + tmetafile, but I get this error when saving to disk (TFileStream) handles are probably really exhausted. However in the same stream, TMetafile is also savetostreamed, something which later apps don't have anymore, and they can run from months.
------------------- UPDATE
I've searched and searched and searched, and managed to reproduce the problems in-vitro two or three times. The problems happened when memusage was +/- 256MB (the systems have 2GB), user objects 200, gdi objects 500, not one file more open than expected ).
This is not really exceptional. I do notice that I leak small amounts of handles, probably due to reparenting frames (something in the VCL seems to leak HPalette's), but I suspect the core cause is a different problem. I reuse TMetafile, and .clear it inbetween. I think clearing the metafile doesn't really (always?) resize the resource, eventually each metafile in the entire pool of tmetafile at maximum size, and with 20-40+ tmetafiles (which can be several 100ks each) this will hit the desktop heap limit.
That's theory, but I'll try to verify this by setting the desktop limit to 10MB at the customers, but it will be several weeks before I have confirmation if this changes anything. This theory also confirms why this machine is special (it's possible that this machine naturally has slightly larger metafiles on average). Occasionally freeing and recreating a tmetafile in the pool might also help.
Luckily all these problems (both tmetafile and reparenting) have already been designed out in newer generations of the apps.
Due to the special circumstances (and the fact that I have very limited test windows), this is going to be a while, but I decided to accept the desktop heap as an example for now (though the GDILeaks stuff was also somewhat useful).
Another thing that the audit revealed GDI-types usage in a thread (though only saving tmetafiles (that weren't used or connected otherwise) to streams.
------------- Update 2.
Increasing the desktop limit only seemed to minorly increase the time till the problem occurred.
Unfortunately, I won't be able to follow up on this further, since the machines were updated to a newer version of the framework that doesn't have the problem.
In summary I can only state what the three core modifications were going from the old to the new framework:
- I no longer change screens by reparenting frames. I now work with forms that I hide and show. I changed this since I also had very rare crashes or exceptions (that could be clicked away) due to this. The crashes were all while operating the GUI though, not spontaneously like the main problem
- The routine where the crash happened dealt with TMetafile. TMetafile has been designed out, and replace by a simpler own made format. (basically arrays with Opengl vertices)
- Drawing no longer happened with tbitmap with a tmetafile overlay strechdrawn over it, but using OpenGL.
Of course it could be something else too, that got changed in the rewrite of the above parts, fixing some very nasty detail bug. It would have to be an extremely bad one, since I analysed the above system as much as I could.
Updated nov 2012 after some private mail discussion: In retrospect, the next step would have been adding a counter to the metafiles objects, and simply reinstantiate them every x * 1000 uses or so, and see if that changes anything. If you have similar problems, try to see if you can somewhat regularly destroy and reinitialize long living resources that are dynamically allocated.
If they are GDI handle leaks you can have a look at MSDN Magazine January 2003 which uses the tool GDILeaks. Other tools are GDIObj or GDIView. Also see here.
Another source of EOutOfResources could be that the Desktop Heap is full. I've had that issue on busy terminal servers with large screens.
If there are lots of file handles you are leaking you could check out Process Explorer and have a look at the open file handles of your process and see any out of the ordinary. Or use WinDbg with the !htrace command.
这篇关于寻找EOutOfResources的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
