Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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 22.214.171.124 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
- 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
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.
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.
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?
I installed Mono 126.96.36.199 (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.
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.
Could you try to reproduce it as well?
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.
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.
Martin, I retested the test code on a brand new Ubuntu VM with Mono 188.8.131.52 (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?
Hello everyone. I faced with the same issue, but on macOS 10.12. I'm using mono 5.2 and also tried mono 184.108.40.206.
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?