I've been tracking down a memory leak using DevPartner 7.2 and what I
am seeing is that calling XmlDocument.Load() leaks A LOT of memory.

The following code is called when I click a button on my test form.
(this is test code I wrote to confirm the bug, not my actual code)


private void button1_Click(object sender, System.EventArgs e)
{
XmlDocument xd = new XmlDocument();
for ( int i = 0; i < 10; i++ )
{
xd.Load( "test.xml" ) ;
Thread.Sleep( 1000 );
}
}

"test.xml" is 8525 bytes.

Each time xd.Load( "test.xml" ) is called, approx 114,000 bytes are
leaked. When I force GC with the DevPartner GUI, all but one of those
are collected, but I am still out 114,000 bytes. I have tried putting
System.GC.Collect() after the Sleep call, but the behavior does not
change.

I am using 2003, does 2005 fix this? Is there a patch? A work around?

Any info greatly appreciated.

This might be a silly question, but are you setting xd to nothing
before calling the GC? Otherwise there will still be an active
reference, and the framework won't release the memory.

"bleedledeep" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've been tracking down a memory leak using DevPartner 7.2 and what I
> am seeing is that calling XmlDocument.Load() leaks A LOT of memory.
>
> The following code is called when I click a button on my test form.
> (this is test code I wrote to confirm the bug, not my actual code)
>
>
> private void button1_Click(object sender, System.EventArgs e)
> {
> XmlDocument xd = new XmlDocument();
> for ( int i = 0; i < 10; i++ )
> {
> xd.Load( "test.xml" ) ;
> Thread.Sleep( 1000 );
> }
> }
>
> "test.xml" is 8525 bytes.
>
> Each time xd.Load( "test.xml" ) is called, approx 114,000 bytes are
> leaked. When I force GC with the DevPartner GUI, all but one of those
> are collected, but I am still out 114,000 bytes. I have tried putting
> System.GC.Collect() after the Sleep call, but the behavior does not
> change.
>
> I am using 2003, does 2005 fix this? Is there a patch? A work around?
>
> Any info greatly appreciated.
>

They are not leaked, the GC did not yet recover them.
The GC will collect the unreferenced objects when HE decides it's time to do
so, calling GC.Collect() to force a collection is in general a very bad
idea.

Willy.

I would like to think that calling Load() again would cause the xd to
clear out the old stuff and have only references to the new stuff, but,
that is an interesting thing to try:

If I do the following, then the 114,000s don't pile up, but I still
never get rid of the last one.

for ( int i = 0; i < 10; i++ )
{
XmlDocument xd = new XmlDocument();
xd.Load( "test.xml" ) ;
Thread.Sleep( 1000 );
xd = null;
System.GC.Collect();
}


Interesting to note that just calling XmlDocument xd = new
XmlDocument(); seems to leak memory, but it is a fixed 592 bytes -
doesn't matter how many times you call it.

Oh, I agree that calling the System.GC.Collect() is bad, and it doesn't
really do it when you ask, but I threw it in there out of curiosity to
try and figure this out, I would never do that in real code.

Forcing the GC from inside the DevPartner does cause an immediate GC,
that is useful as well. That last 114,000 is never recovered.

The problem I have is that in my "real" app, I create 10-20 objects
that suffer this leak, and 114,000 * 20 == ouch.

"bleedledeep" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I would like to think that calling Load() again would cause the xd to
> clear out the old stuff and have only references to the new stuff, but,
> that is an interesting thing to try:
>
> If I do the following, then the 114,000s don't pile up, but I still
> never get rid of the last one.
>
> for ( int i = 0; i < 10; i++ )
> {
> XmlDocument xd = new XmlDocument();
> xd.Load( "test.xml" ) ;
> Thread.Sleep( 1000 );
> xd = null;
> System.GC.Collect();
> }
>
>
> Interesting to note that just calling XmlDocument xd = new
> XmlDocument(); seems to leak memory, but it is a fixed 592 bytes -
> doesn't matter how many times you call it.
>

As I said in another response, this is a BAD thing to do, all you do here is
disturbing the normal working of the GC. This is not a memory leak, you
should definitely read something about the Garbage collection in .NET.

Willy.

"bleedledeep" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Oh, I agree that calling the System.GC.Collect() is bad, and it doesn't
> really do it when you ask, but I threw it in there out of curiosity to
> try and figure this out, I would never do that in real code.
>
> Forcing the GC from inside the DevPartner does cause an immediate GC,
> that is useful as well. That last 114,000 is never recovered.
>
Which is NOT TRUE, they will be recovered when the GC runs, another remark
is that you shouldn't use tools like profilers unless you have a real leak
(that is out of memory exceptions after x execution time).


> The problem I have is that in my "real" app, I create 10-20 objects
> that suffer this leak, and 114,000 * 20 == ouch.
>
Again, this is not a leak, learn the difference between normal behavior and
memory leaks.

Willy.

It will get to out of memory if I create enough of these objects. The
real app is a service that runs for weeks at a time, you can watch it
accumulate memory using task manager. Its memory size should not grow
over the long run. It might over the short-term since, as you said,
the GC runs on its own schedule.

It was only after noticing this behavior that I started to profile it
to see where all that memory was going.

"bleedledeep" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> It will get to out of memory if I create enough of these objects. The
> real app is a service that runs for weeks at a time, you can watch it
> accumulate memory using task manager. Its memory size should not grow
> over the long run. It might over the short-term since, as you said,
> the GC runs on its own schedule.
>
> It was only after noticing this behavior that I started to profile it
> to see where all that memory was going.
>

Noticing what behavior, out of memory exceptions being thrown? I don't
believe it, so please post a small sample that illustrates the issue. And if
it's a real leak GC.Collect() won't help anyway.


Willy.

That's not a leak.

If I create a class with the following:
class t
{
char buffer[592];
}

then I create c as a class of t

t c = new t();

I've allocated c and it has 592 bytes off the top of the bat cause of the
property of buffer.

Think about it, no class would be a length of zero because it wouldn't be
useful in a real world application.

class t
{
}

t c = new t();

how useful is c?



"bleedledeep" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I would like to think that calling Load() again would cause the xd to
> clear out the old stuff and have only references to the new stuff, but,
> that is an interesting thing to try:
>
> If I do the following, then the 114,000s don't pile up, but I still
> never get rid of the last one.
>
> for ( int i = 0; i < 10; i++ )
> {
> XmlDocument xd = new XmlDocument();
> xd.Load( "test.xml" ) ;
> Thread.Sleep( 1000 );
> xd = null;
> System.GC.Collect();
> }
>
>
> Interesting to note that just calling XmlDocument xd = new
> XmlDocument(); seems to leak memory, but it is a fixed 592 bytes -
> doesn't matter how many times you call it.
>