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
Developer Community or GitHub 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.
MonoDevelop is leaking memory badly again. If I don't restart it for a day, it'll hit 1GB+.
Is this with newresolver or master? Also do you have any more info. Is it caused simply by leaving MD running or does it have to be actively used? Does it happen on macos or have you seen it on windows too?
I am running into this as well, with MD 184.108.40.206 on OSX, using Mono 2.10.8. I am working with a large (220k lines of code excluding comments/spaces), 30 project asp.net solution.
I took the time to do some profiling (yes, this was painful). I hit 1.4GB memory usage with monodevelop. Unfortunately, I can't attach the output.mlpd as it's 4.2GB. However, I am attaching the mprof-report, which may give some clues.
I have to restart monodevelop upwards of 8 times a day, which makes it a bit painful sometimes.
Created attachment 1398 [details]
mprof-report output of memory usage
My guess is the "Navigate To" dialog is causing the leak:
2428128 162 14988 MonoDevelop.Ide.NavigateToDialog.NavigateToDialog.MatchResult
And i'm guessing the Navigate To will need file data, and is perhaps not releasing it:
6624544 530 12499 MonoDevelop.Ide.Gui.Workbench.FileData
.. at least these are the ones that seem to stick out.
FileData is a simple struct that contains a filename and a write time, used to track changes to files from outside the IDE. Having 530 sounds quite normal. Similarly, 162 MatchResults is quite typical AFAIK, so probably not a leak.
This looks like a list of allocated object, not live objects. Much of what's on there has probably been collected. To find leaks, you'll need to use heapshot.
ah, ok. will do.
I'm suffering BADLY from this too - however I have only noticed it during debug.
It's happening both during debugging of console applications as well as XSP applications.
After just a couple of minutes, my 8 gb of memory is used, it starts to swap badly and finally Linux decides to kill monodevelop.
I'm on ArchLinux x64, kernel 3.3, mono 2.10.8 and monodevelop 220.127.116.11.
Is there anything I can do to help?
That doesn't sound like the same issue, it sounds much worse. Could you could use heapshot to check whether we have some huge number of uncollected managed objects in that scenario?
When I tried profiling monodevelop with the log:heapshot my console got flooded with messages like this (multiple messages a second):
I stopped the profiling, as nothing really started, relaunched monodevelop as I usually do, while monitoring the log in my home folder - this log is flooded with similar messages. So maybe that is where my leak is located?
I have gtk 3.3.20
Gave it another try where i piped all of the console-output to a file.
In two minues monodevelop consumed 2 GB of ram and produced 798 mb of data on the console (the exception messages over and over again)
The log:heapshot profile result can be downloaded here: http://w596503.open.ge.tt/1/files/1rdgidF/0/blob?download
According to the log:heapshot documentation I had to use the sgen garbage collector, but when I try that i get a segmentation fault in monodevelop?
sgen is required for information about the heap and garbage collection to be gathered so if this is crashing on your system, you will be unable to gather any useful statistics.
I did notice you say you are running Gtk 3. I wonder if this is an issue that only happens with Gtk 3, which is currently unsupported. I cannot reproduce a noticeable memory leak and I've been debugging MonoDevelop within MonoDevelop on a daily basis for the last few weeks. I have even run multiple debugging sessions from the same MonoDevelop instance without it dying from excessive memory consumption.
Okay, I'll give it another shot with the profiler later.
Yes, we have been running GNOME 3.X in Arch Linux since last April where they released the first version.
What is the ETA on Gtk3 support? And can I solve it by installing Gtk2 and then somehow force monodevleop to use it?
Thanks, and sorry if I hijacked the tread with a non-related issue.
Yes, AFAIK GTK+ 2.x is parallel-installable with GTK+ 3.x.
GTK# explicitly uses the -2.0.0 versions of the GTK libraries, eg. libglib-2.0.0.so. Maybe on your system those have been symlinked to the 3.x versions, or the dllmaps have been modified.
I never got around to trying a profile of monodevelop. However, I have created a small patch which fixes my memory leak issues on ArchLinux with GTK3, meaning that I can actually debug applications without bringing down monodevelop.
Would you be interested in the patch?
As long as the patches do not have an adverse affect when running MonoDevelop on Gtk2, we will gladly accept them.
Okay, great, the patch is available here: http://ge.tt/1lpxYSI/v/0
Michael, Should we just commit this patch as-is or do we want to diagnose the root cause of the issue?
If you click the link I posted in comment 9, you can see the type of exceptions that the patch is removing...
NIcklas, I meant we should diagnose why there is a massive memory leak without your patch. We are more than likely failing to free up some memory and it could bite us in more places, so diagnosing the actual leak and seeing if it can be fixed is probably worth doing. If it is not in our code, the fix/bug would need to be upstreamed to gtk.
It really would be better to get to the root of the problem. Nicklas, how did you figure out what to change to fix the leak?
I suppose we can land the patch if it doesn't break anything. I don't know offhand what the implications of these changes are. Maybe Lluis, who wrote the ObjectValueTreeView.cs, can review it?
BTW, in future could you please attach patches to the issue directly, instead of linking to external sites?
I figured it out via Comment 9 - that was what I attempted to say in my last comment (18)...
When I start monodevelop via commandline, and start debugging any application, the log is flooding with the messages that I link to in Comment 9.
All of them are assertion failures, "Gtk-Critical: IA__gtk_tree_view_column_set_fixed_width: assertion `fixed_width > 0' failed" so I though, "hey, let's not set values below 0". This fixed the issue. I have no experience at all with GTK, so I don't know if this breaks something in GTK2.
And yes, of course I can attach things in here - I simply couldn't find the place to do it, so I chose the external approach (I see now that it is in the top of the page).
Created attachment 1996 [details]
Patch for fixing assertion failures in GTK3
The patch fixing memory leak issues on my machine, running GTK3 (same as I linked to previously, but on an external site)
I believe the leak is caused by InternalLogger, which keeps every logged message in a list. I'm going to get rid of the internal log pad and replace it by a "Open log file" command.
If that's the case, then we need to be very careful about logging these messages as we don't want to create multi-terabyte files on the users harddrive ;)
Are these messages all placed in the standard MonoDevelop.log file? If so, should we have a warning/indicator/something to alert the user when there are files greater than a certain size? Or should we stop logging once a file is greater than X megabytes and inform the user logging has been disabled for the remainder of the session?
Note that if we subscribe to the glib messages, then they get printed to stdout, and our redirection will log them anyway. And subscribing and discarding sounds like a really bad idea. I did try rate-limiting a while back, but that's hard to get right. I think limiting the size of the log files to a couple of megabytes if probably the best way. We could also remove old log files more aggressively, e.g. limit by the number of logs, not just by age.
I think, may be that I have a little problem of cpu/mem consumption with MD.
It's using a lot of ram (10-13Go) (not a joke :)
It's using a lot of cpu (one thread eats 100% of one 3.8ghz core)
It's acting like that since the last upgrade 2-3 days ago
(MD 5.10 and Ubuntu 64 14.04)
The Thread eating resources seems to be "GUI Thread".
This has been fixed, as we fixed most of the native leaks in gtk#.