GNOME Bugzilla – Bug 98330
panel leaks 256k on each show/hide
Last modified: 2015-03-24 13:00:35 UTC
I'm running the ximian snapshots: gnome-panel-2.1.2.0.200211081948-0.snap.ximian.1 Over the period of an hour or so the panel will consume all available ram, from: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14119 damon 15 0 11284 11M 7564 S 0.9 4.4 0:04 gnome-panel to: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14119 damon 15 0 48964 47M 7676 S 0.0 19.1 0:13 gnome-panel This was over the period of ~10 minutes. I'm not launching any new applets to cause this behaviour. The panel in question has some launchers, the workspace switcher, the window list, clock weather and gnomeicu. After a while I'm not able to run any new applications from the panel because it complains about not having enough ram to fork a new process. I've noticed this problem over the past few snapshots since roughly the end of October. Killing the gnome-panel process and letting it respawn frees the ram.
I've been watching the gnome-panel process in top. I think I've narrowed it down a bit. When I hit the create new email button in Evolution and it launches a new window, the memory usage jumps quite a bit. Closing this new window makes it jump again. Here are the details: Freshly started panel: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14338 damon 15 0 10624 10M 7480 S 0.0 4.1 0:01 gnome-panel Open a new compose window in Evo: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14338 damon 15 0 29248 28M 7480 S 0.1 11.4 0:03 gnome-panel Close the compose window: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14338 damon 15 0 47724 46M 7480 S 1.1 18.6 0:04 gnome-panel Opening and closing the compose window again: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14338 damon 15 0 84636 82M 7480 S 0.3 33.0 0:07 gnome-panel A few more of these will kill my machine. I'm not sure if its just evo that causes this problem. I'm running Evo 1.2.0 from Red Carpet.
Damon: could you try removing the window list applet to see if the problem is there ?
As requested I removed the window task list applet and killed the gnome-panel process. I then followed the same steps of opening a new message window in Evo and closed it. Ram usage still grows dramatically when I do this.
Damon: thanks for trying this. Does it only happen with evolution or can you see the same behaviour with other applications ? And it would be really great if you could try to do the same thing with just a brand new panel (nothing on it) in order to see if it comes from the panel or a particular applet. Thanks
It happens with a few different apps, but not with others. Galeon 1.2.6 does not cause it to happen, for example. I think gnome-terminal will make it happen though. I'm using the same snapshots at home on another RedHat 7.3 box, and the same testcase does not cause the problem to happen. I deleted my corner panel, as suggested and created a fresh menu panel without any applets. The problem is still occuring. I don't know what is different between home and work that causes it to happen in one place but not the other.
This isn't linux-specific. I've seen the memory leak on sparc Solaris 8, 64-bit. Gnome-panel 2.1.2, compiled from source with gcc-2.95.2. I'll be recompiling with gcc-3.2 and will see if it's still there. I don't know yet what actions trigger the leak on my system.
Strangely, stuff that doesn't seem to be panel-related seem to trigger this. My system was relatively idle, I was logged in remotely, and watched the memory usage climb. The only things active were a background compilation job, and xscreensaver. Shouldn't the priority be higher than "normal"?
Same problem for me, running 2.1.2 built from GARNOME on Debian.
Agreed; this should probably be high priority, since it is (effectively) a crash-causer. Putting it on the radar.
FYI, I recompiled with gcc-3.2 and -O3, and still see the memory leak.
Recompiling with -03 can cause memory leaks itself; please don't report any bugs against anything (more or less) unless you use -02 or less.
gnome-panel-2.1.2.0.200211250553-0.snap.ximian.1 seems to have fixed the problem (at least with my Evolution testcase). I'll keep an eye on it, but (fingers crossed) this is hopefully fixed.
Damon: that's good news. Thanks for looking at this so closely. I'm marking as FIXED - re-open if it starts happening again.
*** Bug 99694 has been marked as a duplicate of this bug. ***
Using gnome-panel 2.1.3 compiled from source with -O2 or -O3 still displays the same behaviour for me. Opening or closing an evolution mail window pushes gnome-panel mem usage up by 7 Megs in my case.
Gnome-panel-2.1.3 compiled from source is now working for me. But if Chris still sees the same behavior, should this be reopened?
Um, spoke too soon. I'm still seeing it with 2.1.3. Is there a difference between this version and the ximian package that Damon reported success with? Please re-open.
I reopen as NEEDINFO. Chris/Peter: are you seeing this only with Evolution or with every application ? Can you try to remove the panels and just add a blank panel to see if it comes from an applet or the panel ? Thanks
Debian, gnome-panel 2.1.3 compiled with gcc3.2 CFLAGS = -O3 -g -march=athlon. I don't seem to see this problem, and I use evolution regularly: 596 javabsp 9 0 11100 9364 6816 S 0.0 3.6 1:29 gnome-panel (this is after it has been run of 12 hours or so)
Ok, my report so far. I removed all applets from the panel, set the background type to default, restarted gnome. The problem still happens. I added a new user. Set the same theme as main user for both gtk and metacity. Remove all applets from panel, removed menu panel from top. (So the desktop is the same as my main user). Start evolution. Reply to a message. Panel usage does NOT increase. Close message. Panel usage also does not increase. Back to original user. Create a new panel with nothing on it. Delete the original panel. killall gnome-panel. Try evolution again. Mem usage increases. I will keep looking...
Next attempt (mv ~/.gconf/apps/panel /tmp), and restarting X also does not fix the problem. I am still trying to find what is different in the two sessions (new user and old user)
I tried logging out of Gnome and removing everything in /tmp/orbit-poshea, but that didn't do anything. I'm not yet able to pin down a case where the bug never happens, and a case when it always happens. Replying to an email in evolution doesn't cause a jump in memory usage for me.
Ok, now I am confused. I have changed no software (as far as I can tell) I have not rebooted, but I have logged out and killed all processes owned by my original user. Now, I can't duplicate the problem any more. Peter - its up to you :)
Okay, I'm assuming this has gone away then ...
For a little while, I thought it was related to the gconf key "keep_menus_in_memory", but I haven't been able to reproduce it in a week.
This needs to be reopened, the problem still seems to be there, even in gnome-panel-2.1.90.1. The growth in memory usage seems to be slower, however. If I turn off the gconf keys keep_menus_in_memory and tooltips_enabled, it seems to go away. I'll try to narrow it down to one of the two. It takes a while, because I have to run for several days to be sure it's happening/not happening.
I'm reopening as NEEDINFO until you get more informations. Thanks for your efforts.
Unfortunately, it doesn't seem like turning off the above two keys fixes it. Still trying things. FYI, on my system, when I start up the panel it is using 4% of my 512M, or about 20M. Over the period of a few days, it climbs up to 10% or so (51M). This is for a single edge panel with translucent background, window list, desktop switcher, five launchers, a clock, a Gnome menu, and a logout button. Earlier on, I tried it with a minimal, non-translucent panel and it didn't go away.
Has anyone run the panel in valgrind to see if that helps?
Could it somehow be related to the comment about eating RAM in this report: http://bugzilla.gnome.org/show_bug.cgi?id=103404 I'll run the panel in valgrind a bit and see what turns up.
There's another leak in the panel reported at: http://bugzilla.gnome.org/show_bug.cgi?id=103503 Any of you autohiding the panel?
I'm not autohiding, and I don't have the clock set to 24 hours and seconds showing.
Ok, testing with the latest panel (2.2.0.1), if I set the panel to autohide and hide/show it a bunch of times, memory usage stays constant. _But_, if I set the prefs to show the hide buttons and manually hide/show it a bunch of times with the button, memory usage creeps up each time. It's going up approx. 256kB each hide/show. This is for a 48x1600 panel (medium), translucent, with one Gnome menu, a few launchers, a window list, and workspace switcher, and a clock. Setting the clock to 24 hour mode and showing seconds doesn't seem to make any difference. Woohoo! I can finally make it leak on purpose!
In addition, if I change the gconf keys to set "keep menus in memory" and "tooltips enabled", the memory increase per hide/show roughly doubles.
As an aside, that "keep menus in memory" option needs to die; it's been causing problems since GNOME 1.2. They should be kept in memory always because it's too slow otherwise.
"keep menus in memory" is gone on HEAD. So, this bug is now "panel leaks 256k on each show/hide". Can we leave this bug as this and only this. Any new leaks should be logged in seperate bugs. I'm reducing the priority/severity because this isn't as severe a leak.
I actually think this bug was fixed by the leak patches that went in recently. Can anyone still confirm this? I've tried autohiding and explicit hiding, but nothing shows a leak this big.
I can no longer make the panel leak, with panel-2.2.1. Autohiding or button-hiding makes no difference. Good work!
Cool, then I'll reopen and mark as fixed.