使用 _crtBreakAlloc、_CRTDBG_MAP_ALLOC 追踪插件中的内存泄漏
我们有几个后效插件，我们有充分的证据表明它们正在泄漏内存。为了调查这个问题，我正在研究 内存泄漏vcc 编译器/运行时中的检测和隔离。我启用了泄漏检测：
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
并且我得到了很好的泄漏转储。但是，我没有得到文件名和行号。我最好的猜测是，这是因为我正在构建一个 dll，它由 After Effects exe 消耗，并且 #define 需要在可执行文件中进行，而不是我的插件（这并不完全符合我的心理模型）这个定义和包含实际上做了什么，但这是我能想到的最好的）。
因此，另一个选择是为特定的内存分配编号设置断点。然而，泄漏的分配并不是一组一致的分配数字，所以我在这方面取得的成功有限。
那么，这里有什么想法吗？如何更好地使用这个工具，或者其他方法来调查这个问题？谢谢！
We have several after effects plugins that we have good evidence are leaking memory. To investigate this, I am playing around with Memory Leak Detection and Isolation in the vcc compiler/runtime. I enabled leak detection with:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
And I get a nice dump of leaks. However, I don't get file names and line numbers. My best guess is that this is because I'm building a dll, which is consumed by the after effects exe, and the #define needs to be made in the executable, not my plugin (this doesn't entirely fit with my mental model of what this define and includes actually do, but it's the best I can come up with).
So the other option is setting breakpoints for specific memory allocation numbers. However, the leaking allocations aren't a set of consistant allocation numbers, so I'm having limitted success with that.
So, any ideas here? Either how to better use this tool, or other ways to investigate this? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您必须使用相同的
#define重新编译这些 DLL - 它们将对malloc()的调用转换为对malloc_dbg()的调用，并且启用转储中的文件名和行号。这就是“泄漏检测”所做的全部工作 - 每个分配都会传递文件名和行号，它们会被存储并稍后转储。没有调用malloc_dbg()- 没有文件名和行号。此外，泄漏转储（所有相关函数）是针对每个运行时的 - 转储是针对当前模块运行时的堆完成的，不一定针对所有模块。由于您的进程中可能有多个 C++ 运行时（每个 DLL 都可以链接到其自己的运行时），因此可能会发生转储未在您期望的运行时完成的情况。
You do have to recompile those DLLs with the same
#defines - they turn calls tomalloc()into calls tomalloc_dbg()and this enables filenames and line numbers in the dump. That's all the "leak detection" does - each allocation is passed the filename and line number and they are stored and later dumped. No calls tomalloc_dbg()- no filenames and no line numbers.Also leak dumps (all related functions) are per-runtime - the dump is done for the heap of the current module runtime, not necessarily for all modules. Since you might have several C++ runtimes in your process (each DLL can be linked against its own runtime) it might happen that the dump is simply not done for the runtime you expect.