检测 Ref-counted COM 对象上的内存泄漏(Addref without Release)
我正在编写一个 Direct3D 10 应用程序,并希望确保没有 COM 对象泄漏。
是的,我用 CComPtr 包装接口,但无论如何我都想进行泄漏检查,出于同样的原因,我仍然使用普通的堆分配泄漏检测器,即使 RAII 和智能指针保证不会泄漏:有时(特别是在接口时)对于像 Direct3D 这样的 C 库),您必须回退到较低的抽象级别并使用原始指针、new、delete,并且您会犯错误。 (更不用说对 Release() 的一些调用在程序结束时不会返回 0)
在包含 atlbase.h 之前我已经 #define _ATL_DEBUG_INTERFACES 但输出窗口中没有出现任何内容!我还需要做些什么才能让 _ATL_DEBUG_INTERFACES 正常工作吗?
I'm writing a Direct3D 10 application and want to make sure I don't have COM objects leaking.
Yes, I am wrapping the interfaces with CComPtr, but I'd like a leak check anyway for the same reason I still use an ordinary heap allocation leak detector even though RAII and smart pointers guarantees there will be no leaks: sometimes (especially when interfacing to a C library like Direct3D) you have to fallback to lower levels of abstraction and use raw pointers, new, delete, and you make mistakes. (Not to mention some calls to Release() don't return 0 at the end of the program)
I've #defined _ATL_DEBUG_INTERFACES before I include atlbase.h but nothing appears in the output window! Is there something else I need to do to get _ATL_DEBUG_INTERFACES to work?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您使用的是 CComPtr,那么这通常是我建议的主要内容,但如果您使用的是 Visual Studio,我确实找到了一些可能有帮助的东西。
Sara Fords 博客有一个非常酷的提示:
在 VS 中调试 AddRef/Release 问题
您可能会记录大量信息,但基本思想是在 Visual 中跟踪 addref/release 调用Studio 和您可以查找不匹配的 AddRef/Release 对。
可能需要一些跑腿工作,但这看起来是一个相当狡猾的想法。
编辑2:早上好;
好的,如果您不使用 DllGetClassObject 那么这不会是引用问题。
使用 IUknown 作为输入/输出参数确实有一个警告;这是来自 MSDN 的 AddRef 简介:
同样对于发布:
If you're using CComPtr then that's generally the main thing I'd advise, but I did find something that might help, if you're using Visual Studio.
Sara Fords blog has a really cool tip:
Debugging AddRef/Release issues in VS
You might get a lot of information logged, but the basic idea is to trace your addref/release calls in Visual Studio and you can look for mismatched pairs of AddRef/Release.
Might be a bit of legwork but it looks like quite a cunning idea.
Edit 2: Good morning;
Ok, if you're not using DllGetClassObject then that's not going to be a reference problem.
Using IUknowns as in/out parameters does have a caveat though; This is the blurb from MSDN for AddRef:
Similarly for release: