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 on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
We found that when we updated to the latest Mono Version (4.2) our services began to show an increase in memory usage, after some profiling and testing and some research we found out it was the Logging section the one to be blamed, this section uses NLog async writting to save different purpose logs. We removed the async part and the problem was fixed. You can find more details here https://github.com/eleonel1/Mono4.2NLogMemoryLeak
Can you offer some information on how to repro the leak ?
I have tried reproducing the leak to no avail on different platforms using installed 4.6 mono. I ran the program, did a request from the browser on the service and then just let the application run indefinitely. In both cases the managed memory slowly grows but it is all collected when a major collection happens.
@Edgar Have you been running with a custom compiled mono, since it looks like it from the --version output ?
As a side note, I did notice increased cpu consumption after a few seconds, going all the way to 99%, while on linux and mac the cpu remains idle. @Niklas could somebody from the windows team investigate if this cpu consumption still happens and why ?
no custom compiled version, just what apt-get installs by default.
Left the test case running for a few days, on linux this time (after accessing the MemoryLeakTest service from the browser) and no leak was observed. Couldn't repro even with 4.2.
If different steps need to be taken to observe the leak let me know, and if you can observe it it would be useful to get the output by passing in the environment MONO_LOG_LEVEL=debug and MONO_LOG_MASK=gc. At this point, not much can be done.
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.