Re: ATL OOM Resource leaks, and inconsistent behavior?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

sorry, the second loop with the m_sappt does not crash.

"Dmitry Streblechenko" wrote:

> The number 354 is the dead giveaway :-)
> Some versions of Outlook/MAPI have problems when MAPIInitialize (called by
> all Redemption objects when created) and MAPIUninitialize (called by all
> Redemption objects when destoyed) are called 300-400 times. To work around
> this problem, create an instance of a Redemption object (any object, such as
> Redemption.MAPIUtils) at your app's startip and keep it referenced until
> your app terminates. This will ensure that the MAPI system will be loaded
> and initialized only once.
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>
> "Leon" <Leon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:5563F8F5-E11C-424E-9B57-223702C927B8@xxxxxxxxxxxxxxxx
> >I FIGURED IT OUT AND THIS IS SOMETHING THAT ALL SHOULD KNOW. HERE IS HOW
> >YOU
> > DO IT:
> >
> > IDispatchPtr iAppt = NULL;
> >
> > for (hr = items->GetFirst(&iAppt); iAppt != NULL && !FAILED(hr); iAppt =
> > NULL, hr = items->GetNext(&iAppt))
> > {
> > Outlook::_AppointmentItemPtr appt(iAppt);
> > appt.AddRef();
> > }
> >
> > You need the extra AddRef(). WHY???? Because the standard initializer
> > does
> > a QueryInterface and Attach() without doing an AddRef. WHY???? I don't
> > know. In this loop, iAppt does a release automatically at the end of the
> > for
> > loop every time iAppt=NULL and appt gets released every time it goes out
> > of
> > scope. Without the AddRef, there is an asymetry. If you use a bare
> > iAppt,
> > the problem is a leak. If you use a smart pointer, there will be a crash
> > at
> > some point. If u do the addRef, there is no crash and no leak.
> >
> >
> >
> > "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
> >>
>
>
>
.

Quantcast