Big Memory Leak in XmlDocument.Load("filename");

[bleedledeep]

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.

 

[BertC]

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.

 

[Willy Denoyette [MVP]]

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.

 

[bleedledeep]

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.

 

[bleedledeep]

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.

 

[Willy Denoyette [MVP]]

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.

 

[Willy Denoyette [MVP]]

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.

 

[bleedledeep]

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.

 

[Willy Denoyette [MVP]]

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.

 

[gabe garza]

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?

 

[Mark Rance]

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.

I sure wish it was better documented when HE was apt to decide to call the
GC routines.

-Mark

 

[Sebastian Dau]

another remark is that you shouldn't use tools like profilers unless you
have a real leak

What the heck of a dirty opinon is what I'm reading here?
Did you ever read the book "George Orwell - 1984"?
Why shouldn't a programmer be allowed to observate his code even without
having heavy trouble with it.
You're telling something like: Don't figure out how nuclear bombs may harm
you unless you die...

Again, this is not a leak, learn the difference between normal behavior
and memory leaks.

Indeed, It will hardly be leak in this propably well tested class but
wouldn't it be better
from you to direct him instead of telling him, that he is wrong?
It's always amazing how bad 3 stupid letters may influence a persons
behavoir.

Microsoft is a Companay in the US not a Religion with head quarters in the
Vatican.

Greets, Sebastian Dau