NetMF HTTP Client Possible Memory Leak

As part of another project I was using the .NetMF HTTPClient functionality to initiate an HTTP GET.

I was having problems with the application crashing after a while so fired up the Visual Studio debugger. Due to a configuration problem the application was kicking of a WebRequest every 10 secs which was significantly faster than intended.

After some poking around I found the application was crashing due to a memory leak of roughly 45K per https call (http is okay). I tried several different ways of declaring/loading the x509 certificate to see if that impacted what the GC could collect but it made little or no difference. I tried forcing a GC after each webrequest but this also appeared to make little or no difference. Basically the BINARY_BLOB_HEAD value increases until the application runs out of memory and then crashes.

To help identify the problem I built a small test harness which reliably reproduces the problem with minimum overhead. The code is available here my HTTP Client Sample.

HTTPS + certificate loaded into a global variable

7120164 bytes
7074420
7029252
6984036
6938952
6893736
6848520
6803304
6758088
6712740

HTTP + certificate loaded into a global variable

7165980 bytes
7167840
7167840
7167708
7167840
7167840
7167840
7167708
7167708
7167840

HTTP – no certificate

7165980 bytes
7167840
7167840
7167840
7167840
7167840
7167840
7167708
7167840
7167840

HTTPS – certificate loaded for every webrequest

7118640 bytes
7073028
7027860
6982644
6937296
6892080
6846864
6801780
6756432
6711348

HTTPS + certificate loaded into a global readonly variable

7118664 bytes
7072920
7027752
6982668
6937452
6892236
6846888
6801804
6756588
6711372

HTTPS Memory info – Start

Type 0F (STRING ): 3084 bytes
Type 11 (CLASS ): 14352 bytes
Type 12 (VALUETYPE ): 1512 bytes
Type 13 (SZARRAY ): 7860 bytes
Type 03 (U1 ): 3192 bytes
Type 04 (CHAR ): 852 bytes
Type 07 (I4 ): 1044 bytes
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 2616 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 7118664 bytes
Type 16 (CACHEDBLOCK ): 216 bytes
Type 17 (ASSEMBLY ): 32688 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 19 (REFLECTION ): 192 bytes
Type 1B (DELEGATE_HEAD ): 864 bytes
Type 1D (OBJECT_TO_EVENT ): 240 bytes
Type 1E (BINARY_BLOB_HEAD ): 152496 bytes
Type 1F (THREAD ): 1536 bytes
Type 20 (SUBTHREAD ): 144 bytes
Type 21 (STACK_FRAME ): 1632 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 144 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 3552 bytes

HTTPS Memory info – Finish

Type 0F (STRING ): 3084 bytes
Type 11 (CLASS ): 14364 bytes
Type 12 (VALUETYPE ): 1512 bytes
Type 13 (SZARRAY ): 7860 bytes
Type 03 (U1 ): 3192 bytes
Type 04 (CHAR ): 852 bytes
Type 07 (I4 ): 1044 bytes
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 2616 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 6711372 bytes
Type 16 (CACHEDBLOCK ): 96 bytes
Type 17 (ASSEMBLY ): 32688 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 19 (REFLECTION ): 192 bytes
Type 1B (DELEGATE_HEAD ): 828 bytes
Type 1D (OBJECT_TO_EVENT ): 240 bytes
Type 1E (BINARY_BLOB_HEAD ): 559476 bytes
Type 1F (THREAD ): 1920 bytes
Type 20 (SUBTHREAD ): 192 bytes
Type 21 (STACK_FRAME ): 1632 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 168 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 3552 bytes


...
using (HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(@"https://www.google.co.nz"))
{
request.Method = "GET";

request.HttpsAuthentCerts = caCerts;

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
if (response.StatusCode == HttpStatusCode.OK)
{
PulseDebugLED();
}
Debug.Print(response.StatusDescription);
}
}
Debug.Print("Memory: " + Microsoft.SPOT.Debug.GC(true).ToString());
...

Time to run Reflector over the system.http assembly and see what is going on. I will also post on tinyclr.com to see if anyone else has encountered anything like this. Without my typo I most probably never have noticed this possible problem before deployment.

One thought on “NetMF HTTP Client Possible Memory Leak

  1. Looks like leak confirmed on http://netmf.codeplex.com/workitem/2005

    John_ghielec wrote Sat at 4:17 AM

    We were able to narrow the leak down. It occurs when you call sslStream.AuthenticateAsClient, which the HTTP classes call when using HTTPs. It occurs on multiple devices with multiple types of interfaces. Built-in Ethernet, SPI Ethernet, and WiFi.

    The attached file shows the point of the leak, line 58.

    John Brochue
    GHI Electronics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s