WishMesh

COM, BSTR or _bstr_t is leaking memory. That was my first thought when I saw increasing number in Task Manager under memory colon for the process I am developing.

Searching Google for quick answer I found famous Microsoft employee and blogger Larry Osterman’s blog post about Hey, why am I leaking all my BSTR’s? He describes OLE caching of BSTR objects and tool called UMDH. OLE caching is not my case, however UMDH may be useful is you are able to figure out what to do.

Another link I found is from 1999 (VS6) Implementing a Simple MFC Client for an ATL Server. They have notes about memory leaks all over the place. Particularly interesting are two examples I have copied below.

Without leak:
//Update static text with new value
BSTR tmpBStr;
 
m_pObject1->get_ObjectString(&tmpBStr);
_bstr_t tmpbstr(tmpBStr, FALSE); //necessary to avoid a memory leak
 
SetDlgItemText(IDC_CURPROPVAL, tmpbstr);

With leak:
//Update static text with new value
BSTR tmpBStr;
 
m_pObject1->get_ObjectString(&tmpBStr);
_bstr_t tmpbstr;
 
tmpbstr= tmpBStr; //Caution: Memory leak occurs
SetDlgItemText(IDC_CURPROPVAL, tmpbstr);

And explanation:

The leak occurs when the tmpbstr variable is initialized. A call to SysAllocString (reference available in the Component Services section of the Platform SDK) is automatically made when creating the tmpbstr variable. This new allocation is never freed later, resulting in a memory leak. Using this version of the _bstr_t constructor avoids the issue by attaching the BSTR object to tmpbstr without a call to SysAllocString. For more information on this issue, see _bstr_t::_bstr_t (reference available in the C++ Language Reference section of the Visual C++ Documentation).

The problem is that explanation is wrong. My speculation: Most probably one person (senior programmer?) found memory leak in documentation, fixed it and told another person (junior programmer?) to update documentation. And that second person got it wrong. First: _bstr_t constructor _bstr_t::_bstr_t() does not allocate memory. Second: if it were allocating, then it would be freed, see the code below:
_bstr_t& _bstr_t::operator=(const wchar_t* s)
{
    if (s == NULL || ...)
    {
        _Free();
        m_Data = new Data_t(s);


And yes, _Free does exactly that. It frees m_Data if it contains something, in our case as I noted above, it points to 0x00000000;

operator=(const wchar_t* s) is exactly what is called in my case – Unicode compile.

Again, the code in Microsoft article leaks memory as comment says, but it does not leak as it is described. It leaks because memory allocated by m_pObject1->get_ObjectString is not freed.

In the end I found my memory leak. It was similar problem, I needed to call _bstr_t constructor with FALSE as second argument. From MSDN: If false, the bstr argument is attached to the new object without making a copy by calling SysAllocString.

So be careful playing with BSTRs.