I can't help but try to post an article: concerning the problem of rtlsizeheap (User breakpoint at address) passing in and out BSTR in vc6

As it turns out, I was able to determine why I was getting this rtlsizeheap problem. being a novice to com and ATL, I had a class that stored a string (_ bstr_t) value. as you wowould perform CT, I had the normal get _ and put _ functions to operate on the member. the problem was, my get _ did not send back a copy of the string held onto by the _ bstr_t Member that I had set up. all I did was assign it (thinking the operator = function actually makes a copy ). since I was using smart pointers, I had the result of the GET _ function assigned to another _ bstr_t. the problem... both _ bstr_t values were looking at the same memory. so no problem wowould occur when the first object goes out of scope as the first _ bstr_t frees the memory it was holding, but when the second object wowould go out of scope... bam rtlsizeheap problem-since the second _ bstr_t was still pointing to memory that was now freed. to solve this, my get _ function was changed:

Stdmethodimp csomeclass: get_m_stotime (BSTR * pval)
{
Afx_manage_state (afxgetappmodulestate ())
If (pval)
* Pval = bstrttotime. Copy ();
Return s_ OK;
}

Summary-rtlsizeheap is definitely not lying-most certainly this error is the result of bstrs and _ bstr_t variables not being handled appropriately. double and tripple check your code-It took me a long time to find this!

Hope this helps!
Dan
// The above is a foreigner's statement, which makes sense

My problem: in external (custom browser control), I want to output a string to Javascript. My original practice is if (pvarresult) * pvarresult = ccomvariant (_ t "myoutstring"); ccomvariant automatically recycles the heap space. So the problem occurs on the =. * Pvarresult is a variant structure variable, and the = operation of this type is not reloaded in the program. Therefore, bstrval points to bstrval in ccomvariant, and ccomvariant automatically recycles it. Therefore, the value of the received variable in JS is unpredictable. When JS exits the living space of the variable, the space of the variable needs to be recycled, so an error occurs. This problem has been clearly stated in msdn, but unfortunately I did not expect it to take a lot of detours.

When creating BSTR and passing them between COM objects, you must handle the memory they use carefully to avoid Memory leakage. When BSTR stays on the interface, its memory must be released after it is used. However, if BSTR passes an interface, the receiving object is responsible for its memory management.
Generally, the rules for allocating and releasing memory allocated to BSTR are as follows:
When you call a function that requires the BSTR parameter, you must allocate memory for the BSTR before calling the function and release it after completing the operation. For example:
Hresult iwebbrowser2: put_statustext (BSTR );

// Shows using the Win32 Function
// To allocate memory for the string:
BSTR bstrstatus =: sysallocstring (L "some text ");
If (bstrstatus = NULL)
Return e_outofmemory;

Pbrostatus-> put_statustext (bstrstatus );
// Free the string:
: Sysfreestring (bstrstatus );
//...
When you call a function that returns BSTR, you must release the string yourself. For example:
Hresult iwebbrowser2: get_statustext (BSTR far * pbstr );
//...
BSTR bstrstatus;
Pbroext-> get_statustext (& bstrstatus );

// Shows using the Win32 Function
// To freee the memory for the string:
: Sysfreestring (bstrstatus );
When you implement the function that returns BSTR, assign a string, but do not release it. The receiving function releases the memory. For example:
// Example shows using MFC's
// Cstring: allocsysstring

//...
Hresult cmyclass: get_statustext (BSTR * pbstr)
{

Try
{
// M_str is a cstring in your class
* Pbstr = m_str.allocsysstring ();
}
Catch (...)
{
Return e_outofmemory;
}

// The client is now responsible for freeing pbstr.
Return (s_ OK );
}
//...