Bug 1884 - MonoDevelop is leaking badly
Summary: MonoDevelop is leaking badly
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: Trunk
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Marius Ungureanu
Depends on:
Reported: 2011-11-04 13:25 UTC by Mikayla Hutchinson [MSFT]
Modified: 2016-11-05 05:34 UTC (History)
8 users (show)

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

mprof-report output of memory usage (420.72 KB, text/plain)
2012-02-21 16:42 UTC, Curtis Wensley
Patch for fixing assertion failures in GTK3 (1.19 KB, patch)
2012-05-31 14:53 UTC, Nicklas Overgaard

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 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.

Related Links:

Description Mikayla Hutchinson [MSFT] 2011-11-04 13:25:55 UTC
MonoDevelop is leaking memory badly again. If I don't restart it for a day, it'll hit 1GB+.
Comment 1 Alan McGovern 2012-02-16 10:45:16 UTC
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?
Comment 2 Curtis Wensley 2012-02-21 16:41:46 UTC
I am running into this as well, with MD 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.
Comment 3 Curtis Wensley 2012-02-21 16:42:17 UTC
Created attachment 1398 [details]
mprof-report output of memory usage
Comment 4 Curtis Wensley 2012-02-24 14:59:23 UTC
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.
Comment 5 Mikayla Hutchinson [MSFT] 2012-02-24 15:48:15 UTC
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.
Comment 6 Curtis Wensley 2012-02-24 15:49:27 UTC
ah, ok.  will do.
Comment 7 Nicklas Overgaard 2012-03-28 12:26:25 UTC
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

Is there anything I can do to help?
Comment 8 Mikayla Hutchinson [MSFT] 2012-03-28 16:38:46 UTC
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?
Comment 9 Nicklas Overgaard 2012-03-29 04:40:49 UTC
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
Comment 10 Nicklas Overgaard 2012-03-29 04:49:22 UTC
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?
Comment 11 Alan McGovern 2012-03-29 05:35:12 UTC
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.
Comment 12 Nicklas Overgaard 2012-03-29 05:58:36 UTC
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.
Comment 13 Mikayla Hutchinson [MSFT] 2012-03-29 13:03:37 UTC
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.
Comment 14 Nicklas Overgaard 2012-05-30 03:40:48 UTC

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?
Comment 15 Alan McGovern 2012-05-30 06:18:31 UTC
As long as the patches do not have an adverse affect when running MonoDevelop on Gtk2, we will gladly accept them.
Comment 16 Nicklas Overgaard 2012-05-31 10:08:48 UTC
Okay, great, the patch is available here: http://ge.tt/1lpxYSI/v/0
Comment 17 Alan McGovern 2012-05-31 10:48:34 UTC
Michael, Should we just commit this patch as-is or do we want to diagnose the root cause of the issue?
Comment 18 Nicklas Overgaard 2012-05-31 10:53:57 UTC

If you click the link I posted in comment 9, you can see the type of exceptions that the patch is removing...
Comment 19 Alan McGovern 2012-05-31 11:20:04 UTC
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.
Comment 20 Mikayla Hutchinson [MSFT] 2012-05-31 14:32:24 UTC
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?
Comment 21 Nicklas Overgaard 2012-05-31 14:51:47 UTC
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).
Comment 22 Nicklas Overgaard 2012-05-31 14:53:03 UTC
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)
Comment 23 Lluis Sanchez 2012-06-01 05:58:29 UTC
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.
Comment 24 Alan McGovern 2012-06-01 06:03:15 UTC
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?
Comment 25 Mikayla Hutchinson [MSFT] 2012-06-01 14:21:39 UTC
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.
Comment 26 MarcoCG 2015-12-04 16:25:44 UTC
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)

Kindest regards
Comment 27 MarcoCG 2015-12-04 16:28:02 UTC
The Thread eating resources seems to be "GUI Thread".
Comment 28 Marius Ungureanu 2016-11-05 05:34:03 UTC
This has been fixed, as we fixed most of the native leaks in gtk#.