Careful with & operator on CComBSTR variables.

Be careful when using the & operator on a CComBSTR variable.  If this variable is not empty, using the & operator on it to point it to a new BSTR will lead to a memory leak.

For instance,

if you have a variable bsz1

declared and initialized as:

CComBSTR bsz1("HiWorld"); 

the member BSTR is allocated by issuing a call to SysAllocString.  If you use somewhere after that  in your code (&bsz1), you will cause a memory leak.


You can call  bsz1.empty() before you use &bsz1 to prevent from the memory leak.




Comments (3)

  1. What’s really strange is that unlike CComPtr, CComBSTR doesn’t even assert that the pointer is NULL in its operator&.

    I heard that this might be fixed in Whidbey, but in the meantime we manually added ATLASSERT(m_bstr == NULL) to our ATL sources. This single change has allowed us to find somewhere around 10-15 BSTR leaks, and generated only a few false positives.

  2. G says:

    Im confused. Can you explain this a little more? Simply taking the address of a CComBSTR causes a memory leak? I dont get it.

  3. Taking the address does not cause the leak. Overwritng the pointer with something else does:

    CComPtr<IXMLNode> spNode1, spNode2;

    CComBSTR bstr;

    spNode1->get_text (&bstr);

    spNode2->get_text (&bstr);

    The second get_text() call leaks the BSTR allocated by the first one.

Skip to main content