Re: ATL OOM Resource leaks, and inconsistent behavior?

I did as u said and stripped the loop to nothing but:

Redemption::ISafeAppointmentItemPtr sappt("Redemption.SafeAppointmentItem");
IDispatch *iAppt = NULL;
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.





"Dan Mitchell" wrote:

> "=?Utf-8?B?TGVvbg==?=" <Leon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> news:9B781963-8624-4E1D-8F2B-9CF7D5E286D2@xxxxxxxxxxxxx:
> > I am doing a release in the last part of the for loop.
>
> Oh, so you are, sorry, I didn't read the code carefully enough, I
> wasn't expecting the comma operator there.
>
> > I changed the
> > code as follows, and now I get a consistent crash on a not so big
> > folder about half way through the appointments inside AtlComPtrAssign,
> > probably when it's doing the assignment on GetNext or iAppt=NULL,
> > where (*pp)->Release() crashes. Which means that the item is already
> > freed or stepped on. Here is what the updated code looks like:
>
> Just to eliminate one thing, are you sure that every object in that
> folder is an appointment? I can't think of an obvious reason why it
> would crash just on one item differently to all the other ones; maybe
> every other time through you're getting lucky and the freed memory
> hasn't been reused yet, but on that one item malloc et al happen to
> shuffle stuff around and finally stomp on something that you're trying
> to reuse.
>
> As a different, more annoying, thing to try, what happens if you go
> back to raw IDispatch everywhere? Heck, you could presumably go with
> IUnknown everywhere, as long as Redemption'll take it -- that would let
> you QI things as you go through just to make sure that they're
> supporting the interfaces you expect.
>
> You'd need to remember to release() stuff by hand, but it would at
> least mean you'd know for certain what was going on, and hopefully that
> might reveal what's going on enough that you can put the smart pointers
> back in.
>
> (heck, if you were feeling really brave, you could do all the dispatch
> stuff by hand and call GetIDsOfNames/GetTypeInfo/etc, but I don't think
> that would gain you much except for a bunch of pain. Then again, it
> might be easy to copy the relevant bits of code out of the tlh/tli files
> that #import has generated.)
>
> Sorry I don't have anything more specific to suggest, but maybe this'll
> shake out whatever's going on.
>
> -- dan
>
.

Relevant Pages

  • Re: Fast string operations
    ... > is why people use unsafe code now and then to use pointer arithmetic to ... > loop over arrays without all the unnecessary bounds checking. ... don't return the trimmed string". ... The customer perceives this as a memory leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Performance Improvement of complex data structure (hash of hashes of hashes)
    ... Anno Siegel wrote: ... >> Here is the code that I'm using to build up this data structure. ... loop through and increment the ... I know that memory allocation in C is expensive, ...
    (comp.lang.perl.misc)
  • Re: Time to fix my PC
    ... intermittently bad) is the power supply 'system'. ... Intermittent memory often passes all tests at room temperature. ... Responsible computer manufacturers provide comprehensive hardware ... such as the crash code or data from system logs in the OS ...
    (comp.os.linux.hardware)
  • Re: Cost of calling a standard library function
    ... It accesses/reads memory using esi 4 ... > safly move it within the cache, without having to go via ebx. ... try it the same thing on a different earlier CPU, ... should check it out...for "tight inner loop" stuff, ...
    (alt.lang.asm)
  • Re: Time to fix my PC
    ... Intermittent memory often passes all tests at room temperature. ... such as the crash code or data from system logs in the OS ... only certain hardware can crash a properly designed ... I'll pull out the audio and DVD drives while testing to simplify ...
    (comp.os.linux.hardware)
Loading