Large static System.Byte[]

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We coded our own stand-in for System.ConfigurationSettings that is using and
XmlReader to pull in the key/value pairs from the
configuration\appSettings\add elements in the .config file, and add them to a
NameValueCollection. CLR Profiler tells me that XmlReader is allocating a
64K System.Byte[] that seems to survive garbage collection for the life of
the application. So I put together a simple repro that on button_click just
instantiaties an XmlTextReader, passing it a new FileStream, and then
immediately closes the XmlTextReader, allowing it to go out of scope, and
thus it and its resources should get garbage collected... CLR Profiler still
shows a 64K System.Byte[] that lives for the life of the application. A GC
Heap snapshot from remote performance monitor shows it in red as

[root: Static (Sytem.Xml.XmlCharType)] System.Byte[](Size: 65548 Bytes, ID:
0x00038007)

Can anyone shed light?
 
Going out of scope doesn't cause collection. If you explicitly call
GC.Collect what happens? In fact I'd call it twice in case it has a
finalizer. 64k is expected as that's the granularity of VirtualAlloc, which
I'd assume it's using for backing.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com
 
Right - it goes out of scope, and then when you click "GC Heap" in remote
performance monitor, it kicks of a collection, and then shows you the objects
that survived that collection, and this byte array always survives. I'll go
ahead and add a GC.Collect in the code to see if it makes a difference, but
just wanted to get this replied to incase there are any other ideas.

Going out of scope doesn't cause collection. If you explicitly call
GC.Collect what happens? In fact I'd call it twice in case it has a
finalizer. 64k is expected as that's the granularity of VirtualAlloc, which
I'd assume it's using for backing.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com



Brandon said:
We coded our own stand-in for System.ConfigurationSettings that is using
and
XmlReader to pull in the key/value pairs from the
configuration\appSettings\add elements in the .config file, and add them
to a
NameValueCollection. CLR Profiler tells me that XmlReader is allocating a
64K System.Byte[] that seems to survive garbage collection for the life of
the application. So I put together a simple repro that on button_click
just
instantiaties an XmlTextReader, passing it a new FileStream, and then
immediately closes the XmlTextReader, allowing it to go out of scope, and
thus it and its resources should get garbage collected... CLR Profiler
still
shows a 64K System.Byte[] that lives for the life of the application. A
GC
Heap snapshot from remote performance monitor shows it in red as

[root: Static (Sytem.Xml.XmlCharType)] System.Byte[](Size: 65548 Bytes,
ID:
0x00038007)

Can anyone shed light?
Click to expand...
Click to expand...
 
Here's my simple little repro - the Sytem.Byte[] lives on...

private void btnLog_Click(object sender, EventArgs e)
{
string configFile = "\\Program
Files\\TestLogger\\TestLogger.exe.config";
XmlTextReader xmlReader = new XmlTextReader(new
FileStream(configFile, FileMode.Open, FileAccess.Read));
xmlReader.Close();
xmlReader = null;

GC.Collect();
GC.Collect();
}

Going out of scope doesn't cause collection. If you explicitly call
GC.Collect what happens? In fact I'd call it twice in case it has a
finalizer. 64k is expected as that's the granularity of VirtualAlloc, which
I'd assume it's using for backing.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com



Brandon said:
We coded our own stand-in for System.ConfigurationSettings that is using
and
XmlReader to pull in the key/value pairs from the
configuration\appSettings\add elements in the .config file, and add them
to a
NameValueCollection. CLR Profiler tells me that XmlReader is allocating a
64K System.Byte[] that seems to survive garbage collection for the life of
the application. So I put together a simple repro that on button_click
just
instantiaties an XmlTextReader, passing it a new FileStream, and then
immediately closes the XmlTextReader, allowing it to go out of scope, and
thus it and its resources should get garbage collected... CLR Profiler
still
shows a 64K System.Byte[] that lives for the life of the application. A
GC
Heap snapshot from remote performance monitor shows it in red as

[root: Static (Sytem.Xml.XmlCharType)] System.Byte[](Size: 65548 Bytes,
ID:
0x00038007)

Can anyone shed light?
Click to expand...
Click to expand...
 
Try:

string configFile = "\\Program Files\\TestLogger\\TestLogger.exe.config";
using (XmlTextReader xmlReader = new XmlTextReader(new
FileStream(configFile, FileMode.Open, FileAccess.Read)))
{
bla...
}

....or even...

using (FileStream fs = new FileStream(configFile, FileMode.Open,
FileAccess.Read))
{
using (XmlTextReader xmlReader = new XmlTextReader (fs))
{
bla...
}
}
 
I'm not sure what the theory is here, but I gave it a try, and the byte array
is still surviving garbage collection.

string configFile = "\\Program Files\\TestLogger\\TestLogger.exe.config";
using (FileStream fs = new FileStream(configFile, FileMode.Open,
FileAccess.Read))
{
using (XmlTextReader xmlReader = new XmlTextReader(fs))
{
xmlReader.Close();
}
}
GC.Collect();
GC.Collect();
 
I have no more theories - but I'd love to know the answer when you find it.
If it is a leak, it seems to be in way too obvious a spot to have not been
caught by internal testing, but who knows (not I).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com
 
Back
Top