Delphi 修复内存泄漏

我最近发现Delphi有一个名为ReportMemoryLeaksOnShutdown的全局变量，当设置为True时，将在应用程序关闭时检测内存泄漏。我在阅读关于另一个相关问题的评论时发现：

因此，从项目源代码中，我将ReportMemoryLeaksOnShutdown:=True

现在，当我的应用程序关闭时，它会发现大量内存泄漏。我的直接想法是检查创建的对象是否被正确释放尝试..最终..释放等

我已经检查了代码，我看不到泄漏可能来自何处，现在我需要找到它们，因为如果在应用程序退出时报告内存泄漏，那么这在很大程度上意味着在运行时存在内存泄漏，这将导致内存泄漏的规模增大，而且是不好的

从上面的链接中，推荐使用第三方工具，如Eureka Log。有没有办法只使用IDE和调试器来帮助我找到并修复问题区域

更新

我设法消除了大约6个内存泄漏，我发现这与MDI儿童有关。child在列表框中保存着一些指针数据，当主应用程序关闭时，它没有正确释放child，这一点现在已经得到修复

我现在只剩下以下两个错误：

---

我发现了这篇文章，这篇文章可能暗示调试器对我的上述错误负有责任？

最好的方法是让工具告诉导致泄漏的分配发生在哪里。为此，您需要下载并使用FastMM的完整版本。随Delphi提供的版本不具备该功能

使用完整的FastMM时，将生成一份报告，其中包含您需要的所有血淋淋的详细信息，包括堆栈跟踪，以告诉您泄漏了哪段代码。

首先，请确保您得到了。它有一些额外的功能，例如FullDebugMode，这将在这里帮助您。使用编译器选项中定义的FullDebugMode和“LogMemoryLeaksToFile”设置以及与EXE位于同一文件夹中的FullDebugMode DLL重新生成项目。除对话框外，这将生成一个文件，其中包含程序shtudown中内存泄漏的详细信息。这里最有用的信息是每个分配的部分堆栈跟踪

一旦有了这些信息，就可以开始修复内存泄漏。这里有一个小技巧：记住对象所有权通常看起来很像一棵树：一个对象拥有其他对象，每个对象拥有其他对象，依此类推。因此，您首先要查找泄漏数量最少的泄漏类型，因为这可能是树的根

---

例如，如果报告说您正在泄漏一个TObjectList和1000个TMyObject实例，那么这些TMyObject实例很可能已分配给该列表，而您只是忘记释放该列表。修正这一点将清除整个报告，因此，在排除其他因素之前，不要到处寻找单个子对象。

可能没有真正的泄漏，但在应用程序关闭时，您以前分配的一些静态对象仍在内存中。请阅读。首先要注意的是，如果基于组件的对象（包括控件）存在漏洞，则不必担心它们总是将父控件传递给构造函数。Delphi负责为您发布这些。但是，如果您有任何TPersistent或TObject子体，则需要手动释放这些子体。“泄漏报告”对话框应该告诉您导致泄漏的类名！只有当应用程序在关闭时出现访问冲突时，我才会看到UnicodeString泄漏，而这从来不会显示应用程序没有正确退出，它会强制自己关闭，从而抑制访问冲突消息。检查以确保您没有释放已释放的对象！从我的经验来看，这是一个共同的原因！我认为它会从工具提示中泄漏字符串。不管怎样在没有调试器的情况下运行，如果仍然看到这些泄漏，则它们是真实的。