Re: Memory leakage in BHO
tomek@x-city.com.ua wrote:
I need to create dynamically COM objects inherited from IDispatch. And
a pointer to the object casted to IDispatch* must be assigned to a
handler - in my case it is a form submit handler. That is, an object
corresponds to each form. As soon as sumbit was invoked, my handler
first does all it has to do, and then I manually call old handler. ALl
seems ok, but I am concerned about the deletion of object.
CComObject<FormSubmitSink> *sink;
sink=new CComObject<FormSubmitSink>();
if (varOld.vt==VT_NULL)
sink->Initialize(m_spBrowser,NULL);
else
sink->Initialize(m_spBrowser,varOld.pdispVal);
var.pdispVal=(IDispatch*)sink;
Here class FormSubmitSink inherited from IDispatch. Will there be any
leaks?
The code does not show how FormSubmitSink instances are disposed of. As
it stands, they appear to never be freed.
Also be aware that you create FormSubmitSink object with an initial
reference count of zero. It is rather risky to keep around an object
with zero reference count: a seemingly benign AddRef/Release pair will
lead to its premature destruction.
Further, you seem to store such un-AddRef'ed pointer in a VARIANT. This
is also wrong. VARIANT owns this interface pointer, so it should be
AddRef'ed before it's stored. Otherwise, when the VARIANT is cleared, it
will Release the pointer. The reference count will wrap around from 0 to
a very large value, which will likely result in the object never being
deleted.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925