Re: ATL OOM Resource leaks, and inconsistent behavior?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Didn't help. I had the call to initialize the redemption object at the
folder level, so it was being called only once per folder. I moved it up to
the initialization code so that it no longer initializes in any loop. I
completely commented out the entire loop and removed the manual AddRef calls
that I had before to test this out. Here is the code in a nutshell. It
still crashes this way after the 354th item on iAppt=NULL; execution.

IDispatchPtr iAppt = NULL;

for (hr = items->GetFirst(&iAppt); iAppt != NULL && !FAILED(hr); iAppt =
NULL, hr = items->GetNext(&iAppt))
{
Outlook::_AppointmentItemPtr appt(iAppt);
}

It crashes the same way in this loop too:

IDispatchPtr iAppt = NULL;

for (hr = items->GetFirst(&iAppt); iAppt != NULL && !FAILED(hr);
m_sappt->put_Item(NULL), iAppt = NULL, hr = items->GetNext(&iAppt))
{
m_sappt->put_Item(iAppt);
}


"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
> >>
>
>
>
.

Relevant Pages

  • Re: ATL OOM Resource leaks, and inconsistent behavior?
    ... I had the call to initialize the redemption object at the ... > completely commented out the entire loop and removed the manual AddRef ... >> OutlookSpy - Outlook, CDO ...
    (microsoft.public.win32.programmer.messaging)
  • Re: Should function argument be changed in function body?
    ... usually better to initialize a loop variable right before ... length_of_string(const char *s){ ... > (I agree that modifying function parameters is not something ...
    (comp.lang.c)
  • Re: ccs compiler with pic12ce674?
    ... I modified the program to only toggle pin 5. ... You don't initialize it to ... > directive probably set it to 0 and nothing in your loop gets executed. ... > toggleState to TRUE so GP4 gets set high the first time through. ...
    (comp.arch.embedded)
  • Re: New style DO syntax?
    ... FOR initialize THEN successor WHILE ... at the beginning of the loop so it shouldn't be there. ... The question is not what Universal Iteration Construct ...
    (comp.lang.fortran)
  • Re: ccs compiler with pic12ce674?
    ... I'm not surprise that you see MCLR high. ... You don't initialize it to anything ... directive probably set it to 0 and nothing in your loop gets executed. ... GP4 to 1 before entering the loop and see if it goes low the first time ...
    (comp.arch.embedded)