FastMM 是否检测所有内存泄漏
最近有人建议（我的程序永远不会释放内存。为什么？ ）我的程序泄漏了一些内存。我将 FastMM 设置为激进，当我关闭程序时它报告没有内存泄漏。
不管怎样，我想知道是否存在 FastMM 未检测到的内存泄漏？
更新：我个人不使用 Win API 来分配内存。但我担心我使用的一些第三方组件（不是很多）可能会使用它。您能否让我知道 FastMM 无法拦截的所有可能的 API 调用？我将在我的代码中搜索它们。谢谢。
Delphi 7、Win 7 32 位
FastMM 4.97
我对接口不感兴趣。
Somebody suggested recently ( My program never releases the memory back. Why? ) that my program leaks some memory. I have FastMM set to aggressive and it reports no memory leaks when I shutdown the program.
Anyway, I would like to know if there can be memory leaks that are no detected by FastMM?
Update: I don't personally use Win API to allocate memory. But I am afraid that some 3rd party components I use (not so many) may use it. Can you let me know all possible API calls that FastMM cannot intercept? I will do a search in my code for them. Thanks.
Delphi 7, Win 7 32 bit
FastMM 4.97
I am not interested about interfaces.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我从来不知道 FastMM 无法检测到内存泄漏。
I've never known FastMM to fail to detect a memory leak.
FastMM 是 Windows 内存管理之上的一层。显然，如果您（或某些组件或其他组件）使用 Windows API 来分配内存，那么此类分配会绕过 FastMM，并且您将无法跟踪它。顺便说一句，Delphi 内存管理器本身使用该 API 来分配内存块。因此，如果您需要查看该级别的分配，FastMM 是不够的 - 您必须使用 AQTime 等工具和类似工具（正如我在上一个问题中建议的那样）。
FastMM is a layer on top of Windows memory management. Obviously, if you (or some component or whatever) uses Windows APIs to allocate memory, then such allocation bypasses FastMM and you won't be able to track it. BTW Delphi memory managers themselves use that APIs to allocate chunks of memory. So if you need to see allocations on that level, FastMM is not enough - you must use tools like AQTime and similar (as I suggested in the previous question).
不会，只有 FastMM 分配的内存会发生内存泄漏。
编辑：
也许答案看起来已经包装好了，但事实并非如此！如果有人检查 FastMM 的制作方法，可以看到内存分配的每个指针都被推入（并在 FreeMem 处弹出）到一个堆栈中（有更多堆栈，取决于内存大小），因此在关闭应用程序结束时，FastMM 仅检查堆栈，如果堆栈中有东西，如果有，则报告内存泄漏！
No, only memory leaks which memory was alocated by FastMM.
EDIT:
Maybe the answer looks wrapped but it is not! If anyone check the FastMM haw is made than can see that every pointer of memory alocation is pushed (and poped out at FreeMem) in to one of stacks (there is more stacks, depend of memory size) so at the end of closing application the FastMM only check stacks, if something in stacks, and if it is, than report memory leak!
有几种可能的原因：（适用于任何内存管理器）
There are several possible causes: (which apply to any memory manager)
已经有很多好的答案了，但是有一点还没有提到......
有很多“泄漏”不会被大多数内存泄漏检测器检测到，因为内存被释放，但在它之后不再使用了。例如，对象堆叠在 TObjectList 中。对象被放入对象列表中，但是在使用完它们之后，您不会释放它们。当对象列表被销毁时，它们也会被销毁（例如，当应用程序关闭时，假设 OwnsObject=True）。由于对象实际上已被释放，因此对象不会“泄漏”，但仍然会使您的应用程序随着时间的推移使用越来越多的内存。
FastMM 不会报告这些，因为它只进行“完整运行”分析。为了检测这些，您需要一个允许执行部分运行的内存泄漏检测器，即分析执行期间 A 点和 B 点之间“泄漏”的内容。尤金提到的 AQTime 允许进行此类检查。但请注意，这需要进行一些分析，因为这会产生许多误报（几乎所有“realloc”操作都将被标记为泄漏）。
There is a lot of good answer already, but one point that wasn't mentionned yet...
There is a lot of "leaks" that won't get detected by most memory leak detector since the memory IS freed, but way after it isn't used anymore. For exemple, object stacked in a TObjectList. Object are put in the object list, but after you are done using them, you don't free them. They will be destroyed when the object list is destroyed too (When application close for exemple, assuming OwnsObject=True). Since the objects are actually freed, objects are not "leaked", but still make your application use more and more memory over time.
FastMM won't report those as it only makes "full run" analysis. To detect those, you need a memory leak detector that allows to do partial runs, that is, analyzing what "leaked" between point A and point B during the execution. AQTime that Eugene mentionned allow that kind of checks. But be aware that is takes a bit of analysis because that will yield many false-positive (Pretty much all "realloc" operations will be marked as a leak).
FastMM 不会检测不经过 FastMM 的内存分配的泄漏。
这可以包括来自您使用的第 3 方库或 DLL 的 GlobalAlloc 调用。
编辑：微软的MSDN有一个内存分配方法的不错列表。
这实际上是我在 我的回答您之前的 FastMM 问题。
您可以使用 VMMap 等工具来跟踪 FastMM 无法检测到的内存泄漏。
——杰罗恩
FastMM does not detect leaks of memory allocations not going through FastMM.
This can include GlobalAlloc calls from 3rd party libraries or DLLs you use.
Edit: Microsoft's MSDN has a nice list of memory allocation methods.
This was in fact the problem I mentioned I mentioned in my answer to your previous FastMM question.
You can use a tool like VMMap to track the memory leaks that FastMM cannot detect.
--jeroen