After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 98330 - panel leaks 256k on each show/hide
panel leaks 256k on each show/hide
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.1.x
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 99694 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-11-12 19:08 UTC by Damon Brodie
Modified: 2015-03-24 13:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2



Description Damon Brodie 2002-11-12 19:08:41 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.
Comment 1 Damon Brodie 2002-11-12 20:14:35 UTC
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.
Comment 2 Vincent Untz 2002-11-12 21:58:02 UTC
Damon: could you try removing the window list applet to see if the
problem is there ?
Comment 3 Damon Brodie 2002-11-13 19:53:49 UTC
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.
Comment 4 Vincent Untz 2002-11-15 23:58:27 UTC
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
Comment 5 Damon Brodie 2002-11-18 15:04:18 UTC
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.
Comment 6 Peter O'Shea 2002-11-19 16:20:07 UTC
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.

Comment 7 Peter O'Shea 2002-11-19 21:57:16 UTC
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"?
Comment 8 Abe Fettig 2002-11-20 15:22:03 UTC
Same problem for me, running 2.1.2 built from GARNOME on Debian.
Comment 9 Luis Villa 2002-11-20 17:25:03 UTC
Agreed; this should probably be high priority, since it is
(effectively) a crash-causer. Putting it on the radar.
Comment 10 Peter O'Shea 2002-11-22 15:21:33 UTC
FYI, I recompiled with gcc-3.2 and -O3, and still see the memory leak.
Comment 11 Luis Villa 2002-11-22 19:56:32 UTC
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.
Comment 12 Damon Brodie 2002-11-25 15:40:20 UTC
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.
Comment 13 Mark McLoughlin 2002-11-27 07:23:47 UTC
Damon: that's good news. Thanks for looking at this so closely. I'm
marking as FIXED - re-open if it starts happening again.
Comment 14 David Kennedy 2002-11-27 16:47:35 UTC
*** Bug 99694 has been marked as a duplicate of this bug. ***
Comment 15 Chris Picton 2002-12-02 08:52:47 UTC
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.
Comment 16 Peter O'Shea 2002-12-02 14:27:25 UTC
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?
Comment 17 Peter O'Shea 2002-12-02 15:03:14 UTC
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.
Comment 18 Vincent Untz 2002-12-02 17:57:31 UTC
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
Comment 19 Ka-Hing Cheung 2002-12-03 06:48:55 UTC
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)
Comment 20 Chris Picton 2002-12-03 10:59:20 UTC
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...
Comment 21 Chris Picton 2002-12-03 11:21:16 UTC
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)
Comment 22 Peter O'Shea 2002-12-04 19:02:21 UTC
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.  
Comment 23 Chris Picton 2002-12-05 08:30:32 UTC
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  :)
Comment 24 Mark McLoughlin 2002-12-18 02:15:12 UTC
Okay, I'm assuming this has gone away then ...
Comment 25 Peter O'Shea 2002-12-18 14:04:22 UTC
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.  
Comment 26 Peter O'Shea 2003-01-13 17:24:42 UTC
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.
Comment 27 Vincent Untz 2003-01-13 22:05:39 UTC
I'm reopening as NEEDINFO until you get more informations. Thanks for
your efforts.
Comment 28 Peter O'Shea 2003-01-15 18:45:09 UTC
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.  

Comment 29 Kjartan Maraas 2003-02-01 16:21:03 UTC
Has anyone run the panel in valgrind to see if that helps?
Comment 30 Kjartan Maraas 2003-02-01 16:24:57 UTC
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.
Comment 31 Kjartan Maraas 2003-02-02 12:10:30 UTC
There's another leak in the panel reported at:

http://bugzilla.gnome.org/show_bug.cgi?id=103503

Any of you autohiding the panel?
Comment 32 Peter O'Shea 2003-02-03 15:02:09 UTC
I'm not autohiding, and I don't have the clock set to 24 hours and
seconds showing.
Comment 33 Peter O'Shea 2003-02-06 15:21:26 UTC
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!
Comment 34 Peter O'Shea 2003-02-06 15:25:15 UTC
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.
Comment 35 Havoc Pennington 2003-02-18 16:52:42 UTC
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.
Comment 36 Mark McLoughlin 2003-03-10 00:57:56 UTC
"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.
Comment 37 Kjartan Maraas 2003-03-17 21:01:10 UTC
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.
Comment 38 Peter O'Shea 2003-03-17 21:54:21 UTC
I can no longer make the panel leak, with panel-2.2.1.  Autohiding or
button-hiding makes no difference.  Good work!
Comment 39 Elijah Newren 2003-08-30 14:23:24 UTC
Cool, then I'll reopen and mark as fixed.