GNOME Bugzilla – Bug 351763
Gnome-panel continous increasing of used memory.
Last modified: 2006-08-23 12:11:22 UTC
I have a amd64 sempron with 1Gb of memory and about 2Gb of swap space. I recognize a big memory consumption if the gnome runs for several hours. The gnome-system-monitor shows me that gnome-panel uses a lot of memory. It starts by about 147MB of virtual memory and 17MB of writable memory. It ends by 2.7GB of virtual memory and and 286MB of writable memory. If I want in this last situation to open a menu in the panel I get a message which says not able to allocate more memory. After this I run gnome-panel with valgrind to a point where the panel uses 603MB virtual mem and 330 writable mem (I will attach the report.). I use ubuntu dapper with latest updates. I have a appelt on top and on bottom of my screen and the following applets running menu, window list, volume cntrol, clock and log out button on top. On bottom there are show desktp button, workspace switcher, lock screen buttn, forc quit button, deskbar, revelation, sticky notes, teatime, dictionary, system monitor, sensors applet, lunar clock, weather report, geyes, trash and network monitor. Please ask if you need more informatin.
Created attachment 71087 [details] valgrind output Output of valgrind running with the following options show-reachable=yes, leak-check=yes and leak-resolution=high.
I can reproduce the behaviour. Open eog with some pictures. Everytime you change the displayed picture in eog the virtual memory of gnome-panel is increased by about 10MB.
Wow. That's huge. Looks like most of the leak comes from pango. Behdad, move it back to the panel if you think pango is innocent :-) (I'm not sure about the pango version number, but I believe this is 1.12)
The pango version is 1.12.3.
First, none of the real leaks is in Pango. All the "possibly lost" records from pango seem to be false positives generated by gslice. All the "still reachable" records look very reasonable. I just don't understand why there's so many of them. I suspect someone doing bad things with Pango. Like creating lots of fontmaps. I assume this is a panel with in-process applets. Things to do/check: 1) Install debuginfo stuff (or use a compiled pango) to get better traces. 2) Valgrind with --num-callers=50 so we can see which applet is causing all the activities. 3) Remove applets one by one to see which one is causing the problem. Or do something smarter, like binary searching. Moreover, from the 20000 records in the log, only 1500 involve Pango, so I'm not sure this is even most of the problem.
Created attachment 71243 [details] valgrind output 2 valgrind output with num-callers=50
I find also out that I get a memory increasing everytime I open the preferences from the win list applet. I have installed in my account a icon set called "dropline nuovo". If I change to the gnome default one the memory consumption is reduced then it only increases by 0.1 MB per 5 changed pictures. I will try later without any applet installed.
I removed every applet and I do not see any relevant increased memory consumtpion. Than I added the ubuntu menu and the increasing is going on. So I think the menu applet is the reason and the differences between the two icon sets come from their size.
Ok, this is apparently librsvg issues reported in bug 344235 and "fixed" on 2006-07-22. I say "fixed" because that fix is not optimal. It creates a lot of fontmaps and that's wrong. Please update librsvg, check again, and if still happens, reopen. *** This bug has been marked as a duplicate of 344235 ***
Thank you for your help. I use librsvg 2.14.4 there isn't a new stable release. I do not want to test with a unstable release. If you would provide a patch for librsvg 2.14.4 then I think I would test it.
This patch may do the job: http://bugzilla.gnome.org/attachment.cgi?id=31799&action=view
This patch is for gimp? How can it apply in librsvg?
I tried the following patch http://bugzilla.gnome.org/attachment.cgi?id=66955&action=view but I get the same massive leak.
Pango's keeping circular references to its fonts is none of librsvg's business, as "g_object_unref()'ing" the fontmap should "just work". Anyhoo, this was worked-around in librsvg one month ago. I'd suggest that the Pango folks close this as a duplicate of bug 143542. 2006-07-22 Dom Lachowicz <cinamod@hotmail.com> * configure.in: Bug 348329 make gnome-print dependency optional * rsvg-text.c: Don't leak PangoFt2 fonts (bug 344235). This is a work-around for Pango bug 143542.
This is the way of bugfixing I like. Everyone says the other has to fix it. :-(
Heh... :) Dom, librsvg should be using a single ft2 fontmap. That's why I think the way it was worked around in librsvg is not optimal. Pango can be fixed (and will be at somet point), yes, but recreating fontmaps is not good for other reasons. Throwing away all the cached fonts and glyphs is one of the reasons. And the ft2 backend is more in the deprecated state now. It lacks a lot of functionality that the cairo backend has. Martin, since you already reopened this bug once, I'm not going to dup it again... I can't do much before you try out an updated librsvg that is supposed to fix this.
Behdad: Either way, this is either a duplicate of Pango bug 143542 or librsvg bug 344235. Regardless of whether librsvg's work-around or use of the non-deprecated ft2 backend is "sub-optimal", it no longer leaks fonts. Martin: You've overlooked that this bug is believed to be already fixed. The fix will be in the GNOME 2.16 release. *** This bug has been marked as a duplicate of 143542 ***
Dom: In comment 13 I wrote that I tested the patch that should fix it. The result is that the leak always exists. Behdad & Dom: I am not sure how long does it take until my distribution will use GNOME 2.16, so a 2.14.x release with a fix of that bug would help me more. I do not want to use a unstable release. This isn't a small leak I can live with. About 3GB of memory were wasted.
Martin: the patch that you tested in comment 13 is not the patch I committed on 2006-07-22. It is similar to the Gimp patch Behdad mentioned in comment 11. The patch that should fix the problem is: http://cvs.gnome.org/viewcvs/librsvg/rsvg-text.c?r1=1.65&r2=1.66 The librsvg 2.15.x series is not really "unstable".
Thank you this patch reduces the leakage to about 0.1MB per changed picture. I will add a new valgrind output.
Created attachment 71447 [details] valgrind output 3 Output of valgrind for gnome-panel after applying the patch from comment19.
The major remaining leaks look like the panel isn't freeing the pixbufs it gets from librsvg. I'd suggest opening a new bug against the panel and attaching that valgrind log to it.