检测 Ref-counted COM 对象上的内存泄漏(Addref without Release)

发布于 2024-11-29 16:59:00 字数 360 浏览 1 评论 0原文

我正在编写一个 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

没有你我更好 2024-12-06 16:59:00

如果您使用的是 CComPtr,那么这通常是我建议的主要内容,但如果您使用的是 Visual Studio,我确实找到了一些可能有帮助的东西。

Sara Fords 博客有一个非常酷的提示:

在 VS 中调试 AddRef/Release 问题

您可能会记录大量信息,但基本思想是在 Visual 中跟踪 addref/release 调用Studio 和您可以查找不匹配的 AddRef/Release 对。

可能需要一些跑腿工作,但这看起来是一个相当狡猾的想法。

编辑2:早上好;

好的,如果您不使用 DllGetClassObject 那么这不会是引用问题。
使用 IUknown 作为输入/输出参数确实有一个警告;这是来自 MSDN 的 AddRef 简介:

为您创建的接口指针的每个新副本调用此方法
制作。例如,如果您要从
方法,您必须对该指针调用 AddRef。您还必须致电
在将指针作为输入输出参数传递给
方法;该方法将在复制之前调用 IUnknown::Release
其之上的超值。

同样对于发布:

当不再需要使用接口指针时调用此方法。
如果您正在编写一个带有输入输出参数的方法,请调用
在复制输出值之前释放您传入的指针
在它上面。

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:

Call this method for every new copy of an interface pointer that you
make. For example, if you are passing a copy of a pointer back from a
method, you must call AddRef on that pointer. You must also call
AddRef on a pointer before passing it as an in-out parameter to a
method; the method will call IUnknown::Release before copying the
out-value on top of it.

Similarly for release:

Call this method when you no longer need to use an interface pointer.
If you are writing a method that takes an in-out parameter, call
Release on the pointer you are passing in before copying the out-value
on top of it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文