Re: ATL OOM Resource leaks, and inconsistent behavior?

The problem does not appear to be specific message related. It begins to
happen after the 354th message. In the debugger, I put a breakpoint right on
this message. I could see all the properties it did fine outputing all the
info on the message and then crashed when the AppointItemPtr tried to release
it before getting assigned the next one. I re-ran stopping right on the
354th message and skipped over the iAppt->Release() call. The
AppointmenItemPtr release call did not crash and it was successfully assigned
the next message. All the props were visible and everything came out happy.
I did not skip over the iAppt->Release() call this time and sure enough it
crashed on the next message.

I think that up until this point, it still has not messed with the memory of
all the double released items and then it begins to and we get crashes. This
probably means that you cannot release both times. However, watching the
memory usage, when I don't do the iAppt->Release(). The memory definitely
keeps going up and up.

I looked through the underlying code as it is executing for
AppointmentItemPtr and during the assignment it does a QueryInterface and
then an Attach. There is a comment that says //save the interface without
AddRef()ing. Does this mean that the AppointmentItemPtr, when it is
released, releases the interface, and thereby the original iAppt?

In general, when you do a QueryInterface on a raw IDispatch *, and you get a
new pointer as a result. When you release the interface *, does that also
release the original IDispatch?



"Dan Mitchell" wrote:

> "=?Utf-8?B?TGVvbg==?=" <Leon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> news:EF58AACA-70C5-4F25-A275-9D21A29BFF5B@xxxxxxxxxxxxx:
> > CComQIPtr<Outlook::_AppointmentItem> appt;
> > for (hr = items->GetFirst(&iAppt); iAppt != NULL && !FAILED(hr);
> > hr =
> > items->GetNext(&iAppt)) {
> > appt = iAppt;
> > appt = (IDispatch *)NULL;
> > iAppt->Release();
> > iAppt = NULL;
> > }
> >
> > It reliably crashes in the same place. If I remove the 2 lines:
> > appt=iAppt, appt=(IDispatch *)NULL; There is no more crash. It zooms
> > right through, and memory stays constant.
> >
> > If I leave the 2 lines and remove iAppt->Release(), it does not crash.
> > However, if I repeatedly call this loop, the memory keeps going up.
> >
> > There must be some kind of issue with QIPtr. Thoughts welcome.
>
> I'm still wondering if there's anything suspicious about the message it
> crashes on -- if you remove that particular one from the folder, does
> the problem go away, or is it the 15th (say) message that's the problem
> no matter what message number 15 is?
>
> Can you read any properties from the message that's crashing, ie are
> you sure that appt is valid at that point? (this may have been in
> earlier versions of your code, but presumably in the code that got
> snipped)
>
> What if you do the QueryInterface by hand -- maybe that'll give you
> something more helpful in the return codes.
>
> Also, now that I think about it, what happens if you use the smart
> pointer wrapper Outlook::AppointmentItemPtr that'll be in the #import-
> generated files, rather than CComQIPtr?
>
> At least now we know that it's nothing related to Redemption, which
> definitely helps.
>
> -- dan
>
.