Re: Memory Leak with Recordset?
- From: jalway@xxxxxxxxx
- Date: 17 Oct 2005 17:03:00 -0700
Stephen Howe wrote:
Thanks for the response!
> > I'm using ADO 2.5 with VC++ trying to release a recordset object from
> > memory, however the memory allocated when the recordset was populated
> > is not completely freed. Most of it, in fact, remains in memory.
> > I've read elsewhere (in this ng, post from Feb 1, 1999) that RecordSet
> > fields are AddRef'd but not Released, so that the reference count is
> > not decremented. A bug in ADO, apparently.
> I looked at the Feb 1, 1999 post.
> I am uncertain of this. Not all claims are necessarily correct.
Right. I also found a person who is using ADO for CE, who has the
same problem. Admittedly this is CE, but it was interesting none the
less.
Reference for the record:
Thread title "ADOCE3.1 memory leaks using SQL SELECT"
ng is microsoft.public.ado.windowsce, date Feb 5 2003
Tiny link to posting:
http://tinyurl.com/csetb
The full link:
http://groups.google.com/group/microsoft.public.ado.windowsce/browse_frm/thread/304e6beb4ce697f5/5f63feae10917aee?lnk=st&q=CVOConnection+adoce3.1+memory+leaks+melchin&rnum=1&hl=en#5f63feae10917aee
> I have never seen any confirmed confirmation of this, nor Microsoft
> acknowldege this as a Bug and it has to be said ADO gets hammered every day.
> In any case, why not use ADO 2.8?
It turns out I am. I assumed otherwise, but upon checking using the
registry and component checker, I realize I'm using 2.8.
> > Even if I close the database connection and delete the class that holds
> > the smart pointers for ADO, and call CoUninitialize(), the memory is
> > not released until the app is exited.
> Yes but this is similar to malloc()/free() & new/delete etc which ultimately
> use the heap
> When you call free()/delete, they _DO NOT_ release memory to the OS.
> Instead the memory is returned to the heap manager within the application,
> waiting to be reused again.
I ran a test on this. I allocated an array of 10 million longs, then
deallocated. I toggled for a while and in the task manager, under
virtual memory size (VM size) it did show about a 40 megabyte change
each time I toggled.
> Only when the app quits is the memory released. If it was otherwise,
> malloc()/free() etc would be unbearably slow, constantly allocating/freeing
> memory from the OS. The heap manager is allowing sub-allocation for speed
> purposes.
> Only if you have something non-standard like _heapshrink() is the memory
> really returned to the OS.
> I have not studied what COM interfaces ADO uses for managing memory it uses
> but I bet it is identical in approach as the heap.
> > Interestingly, the memory usage doesn't get any bigger, but it still
> > takes a large chunk of memory.
> Yup. It is likely to be what I said.
You may be right about COM. It hasn't been a problem beyond the fact
that it's gloming onto so much memory. It's just that I'd prefer to
release that memory so that my application is more efficient.
> > count = pRS->RecordCount;
> > sprintf(bNum,"%ld",count);
> > strNum = bNum;
> > pRS->Close();
> > pRS.Release();
> If pRS is a smartpointers, you should not be doing that.
> It is enough to do
> if ((pRS->State() & (long)ADODB::adStateOpen) != 0)
> pRS->Close();
> pRS = NULL; // The smartpointer will call Release here
Yes, I understand. I've been trying lots of things to try and get
the memory back.
Thanks for the feedback,
...John
.
- Follow-Ups:
- Re: Memory Leak with Recordset?
- From: jalway
- Re: Memory Leak with Recordset?
- References:
- Memory Leak with Recordset?
- From: jalway
- Re: Memory Leak with Recordset?
- From: Stephen Howe
- Memory Leak with Recordset?
- Prev by Date: RE: Discussing 3 different strategies for deleting from multiple table
- Next by Date: Re: Runtime Error 91
- Previous by thread: Re: Memory Leak with Recordset?
- Next by thread: Re: Memory Leak with Recordset?
- Index(es):
Relevant Pages
|
|