Memory Leak - Release and Uninstall

Question

IFSUPCUTILSize* size = NULL; CoCreateInstance(CLSID_UTILSize, NULL, CLSCTX_INPROC_SERVER, IID_IFSUPCUTILSize, reinterpret_cast<void**>(&size)); if (size != NULL){ size->Release(); size = NULL; } delete size; 

Do I need to “remove size” in the code above? If I enable the “delete size”, I will have a memory leak because I did not use New. Or is there a new one inside the CoCreateInsatnce call. I am building this using VC ++ 6.

Answer 1

COM interfaces are counted. CoCreateInstance() returns an interface pointer to a COM object whose reference count has already been incremented. Calling Release() decreases the reference count. When the reference count drops to zero, the COM object is automatically freed. DO NOT call delete on the COM interface pointer! Always use only Release() .

Answer 2

From a C ++ point of view, what you do is fine. Calling delete on a null pointer is no-op. However, this is not necessary.

From the point of view of VC ++ 6, I can’t say that, as you know, it does not meet the requirements. I can’t imagine why this could be a problem. But then again, this is definitely not necessary.

Definitely do not call delete on this pointer before it sets to NULL. You have not allocated a new one, so do not call delete. Resource management here takes care of COM functions.

Answer 3

Never try to use delete to release COM servers implemented by another module (this is your case).

• You do not always know if this server is written in C ++. Doing delete on an object other than C ++ is undefined behavior.
• Even if the server is written in C ++, you do not know on which heap it was allocated, and whether delete correctly free memory or cause undefined behavior.
• You call delete the interface pointer declared as having no virtual destructor - undefined behavior.
• You do not always know if a real object or proxy was served to you. Running delete in the proxy is undefined behavior.
• After you called Release() , the object may have already deleted itself, and executing delete again is undefined behavior.
• Perhaps a third party has claimed responsibility for the object — for example, some instance of the global pointer has been set for your object. If you delete , those other pointers will become overhanging, and this will most likely lead to undefined behavior later.

Bottom line: do not use delete in this case ever. Call Release() to release ownership of the object, and that will be enough.

Answer 4

If I include the "delete size", I will have a memory leak because I did not use New.

Usually you do not get a memory leak by calling delete . You can and will get memory corruption many times. They differ from each other: a memory leak means that your program is stored in a memory that it actually does not use, over time, the program may crash if leaked memory continues to grow; memory corruption means that you somehow strayed from important accounting structures in your memory and most likely will crash very soon (at least you have to hope for a crash, the alternative is worse). One of the most common causes of memory corruption is to free the memory from the wrong procedure , especially on Windows (it's a bit of a tradition for overriding malloc and free on UNIX, so UNIX systems often try to do this ).

Or is there a new one inside the CoCreateInstance call

No matter what, inside CoCreateInstance Release() should be handled. At the very least, you should never free memory just because you have a pointer. You need to know how memory was allocated in order to free it correctly.

Answer 5

I assume that size-> Release () frees up OS resources (files, etc.). Therefore, set the delete size immediately after setting the size to zero.