Question

Chromium Embedded（https://code.google.com/p/delphichromiumembedded/）的GuiDemo代码泄漏了几个字节的内存。并不多，但每次停止应用程序时从FastMM获取该消息非常烦人。我猜泄漏是在Chromium界面。该单元有一个初始化部分：

INITIALIZATION
 CefCache := 'cache';
 CefRegisterCustomSchemes := CefOnRegisterCustomSchemes;
 CefRegisterSchemeHandlerFactory('dcef', '', True, TFileScheme);

日志是这样的：

A memory block has been leaked. The size is: 20

This block was allocated by thread 0x1674, and the stack trace (return addresses) at the time was:
40455E 
4050A7 
409C1D 
405622 
4050DC 
4F0D7A 
406598 
406604 
40A6C3 
4F0E28 
764CEE1C [BaseThreadInitThunk]

The block is currently used for an object of class: main$174$ActRec
The allocation number is: 323

--------------------------------2014/10/5 17:11:33--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):
13 - 20 bytes: main$174$ActRec x 1

事情是，我不知道主要的$ 174 $ ActRec是谁。主持演示的单元实际上称为“main.pas”。但是没有其他名为＆＃39; main＆＃39;。

Answer 1

main$174$ActRec与用于支持匿名方法的接口相关联。所以这应该给你一个如何寻找泄漏的线索。

如果您包含了像madExcept，JCL的EurekaLog这样的异常日志记录套件，那么您将从FastMM获得有意义的堆栈跟踪。这也可以帮助您找到泄漏源自何处。

一旦你能找到泄露的东西，就应该有可能找到一种方法将其注册为预期的泄漏。但是，如果您能够确定泄露的内容，那么我建议您尝试找一种不泄漏的方法。

我无法帮助您进一步识别泄漏，因为您没有提供更多信息。这个项目有很多演示，我不知道你正在运行哪一个。

Answer 2

错误告诉您内存块保存 main$174$ActRec类的实例，而不是内存是由main$174$ActRec类分配的。在应用中的某处，正在调用ActRec.Create()，但未调用ActRec.Destroy()。由于您不知道被泄漏对象的确切内存地址，或者至少知道指向该对象的变量的内存地址，因此您无法通过地址进行注册。但是，FastMM的完整版本有一个重载的RegisterExpectedMemoryLeak()函数，它接受类类型和计数作为输入。这允许您告诉FastMM在FastMM开始将它们报告为泄漏之前允许泄漏多少类类型的实例。当然，这意味着您需要访问类类型。如果它是Chromium内部的东西，你可能会失去运气。

使用Chromium Embedded时如何修复此内存泄漏？

2 个答案: