CODEWITHSUNDEEP
c++memory-leakscomreleasedelete-operator
Damn Vegetables
Damn Vegetables

Reputation: 12464

COM, deleting the memory instead of calling Release()

I know very little about COM, and searching Google for COM somhow did not find COM at all (probably because it searched .com address instead).

We are using a video capturing hardware. Its SDK allows us to register a callback when a frame is captured. An object interface is passed as a parameter to that callback, and we can get the large buffer address (to the captured frame pixels) and other information by querying to that object.

Now, it looks like calling Release() does not actually delete the memory but decreases the reference count, and when the count reaches 0, it is deleted, right? So, about that large buffer address mentioned above, how about "delete"ing the buffer using the "delete" keyword?

It seems that our program (not written by me, and the person who wrote the program quit the company) copies the pointer to the buffer into some class but never calls any Release() in the callback. Later, the buffer is "delete'd in the class. It seems Release()ing the frame interface object also deletes the buffer. But are they the same?

COM somehow counts the reference but what happens if user's code just deletes that memory? I am sorry if my question is obscure. In short, is it safe to delete a buffer that was gotten from a COM object.

Simplified code: Suspicious situation

void mycallback(IFrame f)
{
  char* buffer;
  f->GetBuffer(buffer);
  MyClass m(buffer);
  ...
}

MyClass::DeleteBuffer()
{
  delete m_buffer;
}

Upvotes: 0

Views: 209

Answers (3)

Rahul Sundar
Rahul Sundar

Reputation: 490

Dealing with COM interfaces is more trickier :-)

  1. Make sure you match the IUnknown::AddRef() and IUnknown::Release() calls

  2. As long as you are in the same context, you can delete the buffer explicitly, even though you got them from a COM interface. But make sure you nullify the pointer after deletion, so that there is no post handling issues.

    MyClass::DeleteBuffer() { if(m_buffer) { delete m_buffer; m_buffer = null; } }

Upvotes: 0

Hans Passant
Hans Passant

Reputation: 941595

When the code copies the frame buffer content into its own buffer then nothing special happened. The frame buffer is still owned by the COM code, the code's own buffer is still owned by that code. Do not delete the COM buffer, that will invoke undefined behavior when the COM code deletes it too. You should only ever call Release() on a COM interface pointer if you called AddRef() first. In a scenario like this, the AddRef() call was made by the COM code before it invoked the callback. And the Release() call will be made after the callback returns.

Seeing a frame getting copied in a callback is quite normal, the frame buffer normally only stays valid for the duration of the callback. So you have to copy it if you use it later.

If you are chasing a memory leak then this is not likely the culprit. If there was a reference counting problem on the frame buffer then the program couldn't last for more than a minute before having consumed all available memory.

Upvotes: 2

sergeyxzc
sergeyxzc

Reputation: 615

Try to use this place operator delete, CoTaskMemFree

Upvotes: 0

Related Questions