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 would expect, 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 would 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 would 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 TO:
STDMETHODIMP CSOMECLASS :: GET_M_STOTIME (BSTR * PVAL) {AFX_Manage_State (AFXGetAppModuleState ()) IF (pVAL) * pVAL = bstrtTotime.copy (); returnif;}
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 the foreigner, it makes sense
My question: In the External (Custom Browser Control), you want to output a string in JavaScript. My original approach is if (pvarresult) * pvarresult = ccomvariant (_t "myoutstring"); CCOMVARIANT will automatically reclaim HEAP Space. So the problem appears on = number. * PVARRESULT is a Variant structural variable, and the type is not overloaded in the program. When JS exits the variable's living space, it is necessary to recover the space of the variable, so an error. This problem is very clear in MSDN, but unfortunately, I didn't think of it, and I walked a big pile. When you create BSTR and pass them between COM objects, you must carefully process the memory used to avoid memory leakage. When BSTR stays in the interface, its memory must be released after completion of its use. However, if the BSTR passes the interface, the receiving object will be responsible for its memory management. Under normal circumstances, the rules for the memory allocated to the BSTR are as follows: When calling a function that requires a BSTR parameter, you must assign memory for the BSTR before calling, and release it after the operation is completed. For example: HRESULT IWEBBROWSER2 :: PUT_STATUSTEXT (BSTR BSTR);
// shows Using the win32 function // to allocate memory for the string: bstr bstrstatus = :: sysallocstring (l "some text"); if (bstrstatus == null) Return E_OUTOFMEMORY;
PBROWSER-> PUT_STATUSTEXT (BSTRSTATUS); // free the string ::: sysfreeestring (bstrstatus); // ... When coming in a function that returns a BSTR, you must release the string. For example: HRESULT IWEBBROWSER2 :: GET_STATUSTEXT (BSTR FAR * PBSTR); //...bstr Bstrstatus; PBROWSER-> Get_Statustext (& BSTRSTATUS);
// shows using the win32 function // to free the memory (bstrstatus); When the function returns a BSTR, assign a string, but don't release it. The receive function releases memory. For example: // example shows using mfc's // cstring :: allocsystring
//...HResult CMYCLASS :: get_statustext (bstr * pbstr) {
Try {// m_str is a cstring in your class * pbstr = m_str.allocsystring ();} catch (...) {return e_outofmemory;}
// The client is now responsible for freeing pbstr.return (S_OK);} // ...
