Bug 60332 - HttpWebRequest leaks Mono.Security.Protocol.Tls.ClientSessionInfo object when making an HTTPS request
Summary: HttpWebRequest leaks Mono.Security.Protocol.Tls.ClientSessionInfo object when...
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security ()
Version: 5.2 (2017-04)
Hardware: All All
: --- normal
Target Milestone: Untriaged
Assignee: Brendan Zagaeski (Xamarin Team, assistant)
Depends on:
Reported: 2017-10-23 18:04 UTC by Julien Lemay
Modified: 2018-02-16 12:39 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

MWE to reproduce the leak (1.30 KB, text/plain)
2017-10-23 18:04 UTC, Julien Lemay

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 60332 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Julien Lemay 2017-10-23 18:04:55 UTC
Created attachment 25409 [details]
MWE to reproduce the leak

How To Reproduce :

	- Compile and run the program in the attachment file. After a couple of hours,
	you should see that the memory usage have increased and cannot be reduced 
	even with GC.
	- If you let it run even longer, the program will continue to eat memory until
	the OS kills it.
	- When running the program with the log profiler, I can see 
	Mono.Security.Protocol.Tls.ClientSessionInfo objects slowly increasing over 
	time in a linear way and never seems to be disposed. 
Situation Description :

	- In my situation, I have a client device running mono on a 
	custom Linux distribution.
	- The client have limited RAM (2 GB and a more limited version coming soon 
	will only have 1 GB for cost reason).
	- The client must call multiple servers every 2 to 5 seconds to get 
	information from them over HTTPS. The client must run 24/7 and should not be 
	periodically restarted. 

Remarks : 

	- In my test case, to isolate normal memory usage from the memory leak, I 
	called the gargabe collector every minute with a timer. I also used 
	GCSettings.LargeObjectHeapCompactionMode = 
	GCLargeObjectHeapCompactionMode.CompactOnce at every call of the garbage
	- I also added a WebProxy to connect to Internet using the proxy from my workplace.
	- Necessary certificates has been added to Mono trust store with "cert-sync"
	before launching the program.
Comment 1 misc 2017-10-26 19:18:26 UTC

I am experiencing something similar. Application polling multiple endpoints over HTTPS, about 10-20 requests per minute. I have seen this behavior on 5.2, 5.4 on MacOs and Linux. Trying out the profiler today I found that SslStream and MobileAuthenticatedStream had allocated around 1GB.
Comment 2 Marek Safar 2017-10-27 16:30:41 UTC
I can reproduce it with Mono 5.4 but not with Mono 5.8 or newer. Could you please try to check if that's the case also for you?
Comment 3 Julien Lemay 2017-10-30 15:03:32 UTC
I installed Mono (x64) from the Alpha download page and I let the program run for the weekend.

When I came back, Mono.Security.Protocol.Tls.ClientSessionInfo object were still increasing without being disposed and/or removed.

The memory used by Mono tripled between Friday afternoon and Monday morning.
Comment 4 Julien Lemay 2017-11-20 14:30:43 UTC
Is it normal if this issue is still in "NEEDINFO" status? Do you need more information?

We are currently waiting for a fix on this issue to be able to ship our product.
Comment 5 Marek Safar 2017-11-20 22:34:07 UTC

Could you try to reproduce it as well?
Comment 6 Martin Baulig 2017-12-11 20:10:52 UTC
Bug was filed against the old legacy code that's going to be removed.  We will not make any changes / accept patches against Mono.Security.Protocol.Tls.*.

Mono 5.4 was still using the legacy code, 5.8+ is using the new code by default.

I'm not saying we can't have a memory leak - but if we do, then it will not be in Mono.Security.Protocol.Tls.* but somewhere else.
Comment 7 misc 2017-12-11 21:35:16 UTC
I found a bug in my code which was the main culprit, also tweaked connection (idle time + concurrent) and HttpClient settings. I am getting approximately one month uptime with 600MB RAM usage on 5.4, which is enough for me not to put any more effort in to this right now. So please disregard my previous comment.
Comment 8 Julien Lemay 2017-12-13 13:44:33 UTC
Martin, I retested the test code on a brand new Ubuntu VM with Mono (alpha build) and you are right:

1) There is no trace of the old legacy code anymore (replaced by BoringSSL).
2) The leak is not existent anymore (from what I see after 1 day of test).

From what I've just read in Mono 4.8.0 Release Notes, if I want to use BoringSSL to avoid the leak in older release (>=4.8), I should just need to recompile Mono with the environment variable "export MONO_TLS_PROVIDER=btls".
Am I right?
Comment 9 Raman Sidarakin 2018-02-16 12:39:13 UTC
Hello everyone. I faced with the same issue, but on macOS 10.12. I'm using mono 5.2 and also tried mono

To exclude possible bugs in my own code, I've tested example, provided by Julien Lemay in description of this issue. When I compiled & run this example, it started increasing memory usage very intensively (about +3MB every 10 seconds).

One interesting thing here: I've added GC.Collect() to this example, before Thread.Sleep(delay); line and memory consumption is stable and not increasing.

Can you please suggest something?