Bug 160137 - Memory leak when opening new window/file
Memory leak when opening new window/file
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Mark McLoughlin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-11 04:25 EDT by Erwin Rol
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: gnome-panel-2.10.1-10.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-26 12:06:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
valgrind log (445.98 KB, text/plain)
2005-07-20 06:47 EDT, Erwin Rol
no flags Details
gnome-panel valgrind from i386 (139.93 KB, text/plain)
2005-07-20 10:35 EDT, John Saalwaechter
no flags Details
backport of panel 2.11.4 (7.93 KB, patch)
2005-07-20 21:28 EDT, Erwin Rol
no flags Details | Diff

  None (edit)
Description Erwin Rol 2005-06-11 04:25:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
When a window is opened that also opens a new file, for example the pdf viewer, gnome-panel loses memory that isn't returned after closing the window/file. Every time this is done gnome-panel seems to loose about 10MB in memory, causing it to eat up all memory so that other programs can't start anymore due to low memory situation.

Version-Release number of selected component (if applicable):
gnome-panel-2.10.1-10

How reproducible:
Always

Steps to Reproduce:
1. check memory usage of gnome-panel
2. double click on a PDF in nautilus
3. check memory usage of gnome panel
4. close pdf viewer
5. GOTO 1

or

1. Check memory usage of gnome-panel
2. open archive viewer
3. check memory usage of gnome-panel
4. open archive file in archive viewer
5. check memory usage of gone-panel
6. close archive viewer
7. GOTO 1
  

Actual Results:  Everything works normal, appart from the fact that gnome-panel loses more and more memory.

Additional info:


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

13643 erwin     16   0  611m 461m  12m S  0.0 24.5   2:02.01 gnome-panel

Open a new window

13643 erwin     17   0  621m 471m  12m S 42.3 25.0   2:04.89 gnome-panel

Close it

13643 erwin     15   0  621m 471m  12m S  0.0 25.0   2:04.89 gnome-panel

Open a new window

13643 erwin     17   0  629m 479m  12m R 74.2 25.5   2:07.30 gnome-panel

Close it

13643 erwin     15   0  631m 481m  12m S  0.0 25.6   2:07.77 gnome-panel
Comment 1 John Saalwaechter 2005-06-21 16:29:20 EDT
Maybe just the build is bad. I seem to have fixed the problem by simply
rebuilding the gnome-panel RPM on my own workstation and reinstalling it. I
did this:

1. Downloaded the SRPM from 
http://download.fedora.redhat.com/pub/fedora/linux/core/4/SRPMS/gnome-panel-
2.10.1-10.src.rpm
2. # rpmbuild --rebuild gnome-panel-2.10.1-10.src.rpm
3. # rpm -Uhv --force /usr/src/redhat/RPMS/i386/gnome-panel-2.10.1-10.i386.rpm
4. rebooted system

Now the gnome-panel process seems to have a constant virtual size, regardless
of opening/closing windows.  In fact, with the faulty version I ran an
strace against the process watching for brk()s.  When I opened a PDF with
evince, gnome-panel would call brk() many times.  Now with my recompiled
version, it doesn't do it at all.
Comment 2 Mark McLoughlin 2005-06-22 11:54:44 EDT
Hmm, is this is an x86-64 machine, right? When you rebuilt, you installed the
i386 version?
Comment 3 John Saalwaechter 2005-06-22 14:15:09 EDT
(In reply to comment #2)
> Hmm, is this is an x86-64 machine, right? When you rebuilt, you installed the
> i386 version?

Mark, I created some confusion.  The original reporter of this bug may be 
running an x86_64 machine based his web browser User-Agent info above. I've got 
the same problem, so I added Comment #1 above, which all took place on an i386 
install (Linux xxxxxxxx 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 
i686 i386 GNU/Linux).
John
Comment 4 John Saalwaechter 2005-06-23 12:51:42 EDT
(In reply to comment #1)
> Maybe just the build is bad. I seem to have fixed the problem by simply
> rebuilding the gnome-panel RPM on my own workstation and reinstalling it.

OK, looks like recompiling didn't solve the problem. On the day I did it,
gnome-panel held a constant virtual size for a long time, compared to quick
memory growth with the original RPM. But this morning gnome-panel has taken over
1/2 my memory. Back to square one.
Comment 5 John Saalwaechter 2005-06-27 10:13:36 EDT
I got a new clue on this issue from the thread at
http://fedoraforum.org/forum/showthread.php?t=60517.
Someone posted there that using a jpg as the desktop
background has been reportedly linked to memory leaks.
And in fact, I was using one of the stock jpg background
images (/usr/share/backgrounds/images/tiny_blast_of_red.jpg).

I rebooted my system and logged in with that jpg as
my background. I captured the output of
/proc/pid-of-gnome-panel/statm every minute from cron.
The gnome-panel memory size grew quite quickly, even
with just the screensaver running.  Here is sample
one-minute captures of statm when a jpg was my background:

5671 2476 2012 110 0 668 0
6086 2882 2164 110 0 961 0
6213 2951 2176 110 0 1027 0
6363 3053 2189 110 0 1116 0
6394 3101 2196 110 0 1141 0
6520 3162 2208 110 0 1206 0
6639 3227 2220 110 0 1264 0
6639 3252 2224 110 0 1264 0
6639 3252 2224 110 0 1264 0
6913 3412 2253 110 0 1416 0
6913 3414 2253 110 0 1416 0
6913 3414 2253 110 0 1416 0
6913 3414 2253 110 0 1416 0
7028 3479 2265 110 0 1470 0
7028 3479 2265 110 0 1470 0
7028 3479 2265 110 0 1470 0
7028 3479 2265 110 0 1470 0
7028 3479 2265 110 0 1470 0
7028 3479 2265 110 0 1470 0
7143 3544 2277 110 0 1524 0
7143 3544 2277 110 0 1524 0
7182 3606 2287 110 0 1563 0
7309 3673 2300 110 0 1629 0
7309 3673 2300 110 0 1629 0
7309 3673 2300 110 0 1629 0
7309 3673 2300 110 0 1629 0
7309 3673 2300 110 0 1629 0

After that I reset my background to the default png image
(/usr/share/backgrounds/images/default.png), then rebooted,
logged in, and captured /proc/pid-of-gnome-panel/statm
output every minute again. In this case, gnome-panel hasn't
grown. It's held steady at 5671 pages for almost three days
(mainly running the screensaver over the weekend):

5671 2473 2010 110 0 668 0
5671 2473 2010 110 0 668 0
5671 2473 2010 110 0 668 0
5671 2473 2010 110 0 668 0
5671 2473 2010 110 0 668 0

So it appears that having a jpg as the background (instead of
the default png), does correlate to a memory leak in gnome-panel.

One side note: I haven't tested this methodically yet, but in
one case I logged in with default.png as my background, then
switched to tiny_blast_of_red.jpg as my background. Gnome-panel
did not grow in that case. So maybe the bug is triggered by simply
having a jpg as the background at the time of login. Again, I
haven't gone through controlled testing of this single observation.
Comment 6 Mark McLoughlin 2005-06-28 08:02:47 EDT
Okay, I don't think there's anything inherently wrong with what you describe. I
can certainly see the panel's RSS rising from 10M to 14M if you had a large
background image on your desktop, a transparent panel and you used the menus for
a bit. If that extra 4M is a bug, then its a memory optimisation bug.

The bug originally described was of the panel growing in size without bound
until all the system memory was exhausted. That's a very different situation.


So, to the original reporter Erwin - do you still see this bug with FC4? If so,
then:

  - Was it a clean install of FC4?
  - Is this an x86-64 machine?
  - Is this with a long running session or do you see the 10M jumps as soon
    as you log in?
  - Does removing ~/.gnome2/session, logging out and back in again help?
  - Anything unusual about your system?
Comment 7 John Saalwaechter 2005-06-28 09:34:37 EDT
(In reply to comment #6)
> Okay, I don't think there's anything inherently wrong with what you describe. I
> can certainly see the panel's RSS rising from 10M to 14M if you had a large
> background image on your desktop, a transparent panel and you used the menus for
> a bit. If that extra 4M is a bug, then its a memory optimisation bug.
> 
> The bug originally described was of the panel growing in size without bound
> until all the system memory was exhausted. That's a very different situation.

Mark, I'm not talking about the extra memory of the background image itself.
Here's the situation that I can reproduce on my workstation:

If I have default.png as my background, my gnome-panel process quickly settles
to a total size of about 5700 pages of memory and then never grows again.

If I have a jpg as my background, my gnome-panel process grows continuously
until it exhausts all my system memory.  The statm output I included in the
comment above was just a 30-minute snapshot to show the growth rate. With a jpg
background I've seen my gnome-panel go as high as 800MB before I had to stop it.

So, at least on my install, by only switching between the png and jpg
background, I can trigger this behavior of gnome-panel consuming all my memory.
Comment 8 Mark McLoughlin 2005-06-28 09:40:33 EDT
Okay:

  - Was it a clean install of FC4?
  - Does removing ~/.gnome2/session, logging out and back in again help?
  - Anything unusual about your system?

Try running the panel under valgrind for a long period:

  $> gnome-session-remove gnome-panel
  $> GNOME_PANEL_DEBUG=1 valgrind --tool=memcheck --leak-check=yes
--num-callers=20 gnome-panel > t.log 2>&1
Comment 9 John Saalwaechter 2005-07-01 15:38:22 EDT
- Was it a clean install of FC4?
* This was a clean "Everything" install of FC4

- Does removing ~/.gnome2/session, logging out and back in again help?
* I haven't yet tried removing ~/.gnome2/session yet, but I did notice that my 
account stopped exhibiting the problem recently, and I'm not sure what changed. 
I do have an NFS home directory, and I inadvertently logged into a Solaris 10 
workstation and started GNOME, which tweaked stuff in my home directory GNOME 
files. Interestingly the root account still has the problem, and of course its 
home directory is local and not ever modified by other systems.

- Anything unusual about your system?
* Not really, but this is a workstation with NFS home directories and NIS 
accounts.

- Valgrind
I ran gnome-panel under valgrind, but I'm not sure if I captured the leak, 
because valgrind reserves a huge chunk of memory up front and doesn't grow 
itself.

To capture a whole session, I moved /usr/bin/gnome-panel to /usr/bin/gnome-
panel.orig, and then I put this script at /usr/bin/gnome-panel:

    #!/bin/sh
    GNOME_PANEL_DEBUG=1 valgrind \
        --tool=memcheck \
        --leak-check=yes \
        --num-callers=20 \
    gnome-panel.orig "$@" > /var/tmp/gp-$$.log 2>&1

Here are the results of that valgrind session (sorry for the long post):

===============START VALGRIND SESSION======================================
==25862== Memcheck, a memory error detector for x86-linux.
==25862== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==25862== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==25862== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==25862== For more details, rerun with: -v
==25862== 
==25862== Conditional jump or move depends on uninitialised value(s)
==25862==    at 0x28EEF7: strstr (in /lib/libc-2.3.5.so)
==25862==    by 0x46B6E7: __pthread_initialize_minimal (in /lib/libpthread-
2.3.5.so)
==25862==    by 0x46B297: (within /lib/libpthread-2.3.5.so)
==25862==    by 0x46AE7F: (within /lib/libpthread-2.3.5.so)
==25862==    by 0x1B8F1B4A: call_init (in /lib/ld-2.3.5.so)
==25862==    by 0x1B8F1C6C: _dl_init (in /lib/ld-2.3.5.so)
==25862==    by 0x1B8E483E: (within /lib/ld-2.3.5.so)
==25862== 
==25862== Syscall param writev(vector[...]) points to uninitialised byte(s)
==25862==    at 0x2E6F4C: writev (in /lib/libc-2.3.5.so)
==25862==    by 0x38FB87A: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38FBBE7: link_connection_writev (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38DDFAB: giop_send_buffer_write (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38E2274: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38E2A3A: ORBit_small_invoke_stub (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38E2C25: ORBit_small_invoke_stub_n (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38F34E8: ORBit_c_stub_invoke (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x399AF3E: ConfigServer_ping (in /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398372B: gconf_activate_server (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x398EB78: (within /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398F637: (within /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398FA1C: gconf_engine_get_default (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x3993C43: gconf_client_get_default (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x3BCBE82: (within /usr/lib/libgnomeui-2.so.0.1000.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1B9DE51A is 10 bytes inside a block of size 2048 alloc'd
==25862==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==25862==    by 0x6D59FF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x38DDEFD: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38DE2D5: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38DE677: giop_send_buffer_use_request (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38E21CD: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38E2A3A: ORBit_small_invoke_stub (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38E2C25: ORBit_small_invoke_stub_n (in /usr/lib/libORBit-
2.so.0.0.0)
==25862==    by 0x38F34E8: ORBit_c_stub_invoke (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x399AF3E: ConfigServer_ping (in /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398372B: gconf_activate_server (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x398EB78: (within /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398F637: (within /usr/lib/libgconf-2.so.4.1.0)
==25862==    by 0x398FA1C: gconf_engine_get_default (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x3993C43: gconf_client_get_default (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x3BCBE82: (within /usr/lib/libgnomeui-2.so.0.1000.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x6E9009: g_str_hash (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3351: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB28 is 0 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x6E9016: g_str_hash (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3351: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB29 is 1 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x6E9033: g_str_hash (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3351: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB2A is 2 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x6E904A: g_str_hash (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3351: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB2B is 3 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x1B90A15C: strcmp (mac_replace_strmem.c:250)
==25862==    by 0x6E8FF3: g_str_equal (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3378: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB28 is 0 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Invalid read of size 1
==25862==    at 0x1B90A16B: strcmp (mac_replace_strmem.c:250)
==25862==    by 0x6E8FF3: g_str_equal (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6C3378: g_hash_table_lookup (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x3995083: gconf_client_remove_dir (in /usr/lib/libgconf-
2.so.4.1.0)
==25862==    by 0x809ADAC: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1BD3CB29 is 1 bytes inside a block of size 36 free'd
==25862==    at 0x1B909743: free (vg_replace_malloc.c:152)
==25862==    by 0x6D5B43: g_free (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x809AD95: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B4A0: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x809B89D: panel_profile_load (in /usr/bin/gnome-panel.orig)
==25862==    by 0x80641CD: main (in /usr/bin/gnome-panel.orig)
--25862-- WARNING: unhandled syscall: 272
--25862-- Do not panic.  You may be able to fix this easily.
--25862-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--25862-- WARNING: unhandled syscall: 272
--25862-- Do not panic.  You may be able to fix this easily.
--25862-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--25862-- WARNING: unhandled syscall: 272
--25862-- Do not panic.  You may be able to fix this easily.
--25862-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--25862-- WARNING: unhandled syscall: 272
--25862-- Do not panic.  You may be able to fix this easily.
--25862-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--25862-- WARNING: unhandled syscall: 272
--25862-- Do not panic.  You may be able to fix this easily.
--25862-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
==25862== 
==25862== Syscall param write(buf) points to uninitialised byte(s)
==25862==    at 0x4710BB: (within /lib/libpthread-2.3.5.so)
==25862==    by 0x3E146B: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0x3C680A: (within /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0x3C6925: _XReply (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0x3C14F2: XSync (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0xDA15C0: gdk_display_sync (in /usr/lib/libgdk-x11-
2.0.so.0.600.7)
==25862==    by 0xC79B8B: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xC790AD: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x1B57A6: bonobo_socket_add_id (in /usr/lib/libbonoboui-
2.so.0.0.0)
==25862==    by 0x1AEE86: bonobo_control_frame_get_remote_window 
(in /usr/lib/libbonoboui-2.so.0.0.0)
==25862==    by 0x1B5A4E: (within /usr/lib/libbonoboui-2.so.0.0.0)
==25862==    by 0x771816: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x765D9A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x766284: g_closure_invoke (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x7743DF: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x775EDF: g_signal_emit_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x776253: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0xC65850: gtk_widget_realize (in /usr/lib/libgtk-x11-
2.0.so.0.600.7)
==25862==    by 0xC65A0E: gtk_widget_map (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xB047D5: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==  Address 0x1B9A44FE is 14 bytes inside a block of size 16384 alloc'd
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x3B6DD9: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0xDA0B0D: gdk_display_open (in /usr/lib/libgdk-x11-
2.0.so.0.600.7)
==25862==    by 0xD83863: gdk_display_open_default_libgtk_only 
(in /usr/lib/libgdk-x11-2.0.so.0.600.7)
==25862==    by 0xB827CD: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xB82800: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x1A9C6D: (within /usr/lib/libbonoboui-2.so.0.0.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== Syscall param write(buf) points to uninitialised byte(s)
==25862==    at 0x4710BB: (within /lib/libpthread-2.3.5.so)
==25862==    by 0x3E146B: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0x3C680A: (within /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0x3AAA98: XFlush (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0xDA166A: gdk_display_flush (in /usr/lib/libgdk-x11-
2.0.so.0.600.7)
==25862==    by 0xD9B6B7: gdk_window_process_all_updates (in /usr/lib/libgdk-
x11-2.0.so.0.600.7)
==25862==    by 0xB02BA4: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x6D164F: (within /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6CF3ED: g_main_context_dispatch (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x6D23F5: (within /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6D26E2: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0xB831B4: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x80641F6: main (in /usr/bin/gnome-panel.orig)
==25862==  Address 0x1B9A4619 is 297 bytes inside a block of size 16384 alloc'd
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x3B6DD9: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==25862==    by 0xDA0B0D: gdk_display_open (in /usr/lib/libgdk-x11-
2.0.so.0.600.7)
==25862==    by 0xD83863: gdk_display_open_default_libgtk_only 
(in /usr/lib/libgdk-x11-2.0.so.0.600.7)
==25862==    by 0xB827CD: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xB82800: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x1A9C6D: (within /usr/lib/libbonoboui-2.so.0.0.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
ALSA lib conf.c:1578:(snd_config_load1) _toplevel_:51:23:No such file or 
directory
ALSA lib conf.c:2821:(snd_config_hook_load) /etc/alsa/cards/aliases.conf may be 
old or corrupted: consider to remove or fix it
ALSA lib conf.c:2684:(snd_config_hooks_call) function snd_config_hook_load 
returned error: No such file or directory
ALSA lib pcm.c:1959:(snd_pcm_open_conf) Invalid type for PCM default definition 
(id: default, value: cards.pcm.default)
==28431== 
==28431== ERROR SUMMARY: 173 errors from 10 contexts (suppressed: 129 from 4)
==28431== malloc/free: in use at exit: 2980690 bytes in 64203 blocks.
==28431== malloc/free: 546717 allocs, 482514 frees, 26275046 bytes allocated.
==28431== For counts of detected errors, rerun with: -v
==28431== searching for pointers to 64203 not-freed blocks.
==28431== checked 5544136 bytes.
==28431== 
==28431== 
==28431== 8 bytes in 1 blocks are definitely lost in loss record 23 of 213
==28431==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==28431==    by 0x6D5A6D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x6CA729: (within /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x6CAF05: g_key_file_get_string (in /usr/lib/libglib-
2.0.so.0.600.4)
==28431==    by 0x5D45E3: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D535D: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D5DC9: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D5EC7: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D5E22: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D624D: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D7B3E: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5D7C38: menu_layout_node_menu_get_app_dirs 
(in /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5DA1A0: (within /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x5DB3F7: menu_tree_get_root_directory (in /usr/lib/libgnome-
menu.so.0.0.0)
==28431==    by 0x5DB5A7: menu_tree_get_directory_from_path 
(in /usr/lib/libgnome-menu.so.0.0.0)
==28431==    by 0x807C3A4: (within /usr/bin/gnome-panel.orig)
==28431==    by 0x771816: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431==    by 0x766284: g_closure_invoke (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431==    by 0x77478A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x775EDF: g_signal_emit_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431== 
==28431== 
==28431== 36 bytes in 3 blocks are definitely lost in loss record 71 of 213
==28431==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==28431==    by 0x6D59FF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x6E7C3A: g_strdup (in /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x17C6C1: (within /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x17CAD3: bonobo_activation_i18n_get_language_list 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x17CF1F: bonobo_activation_register_client 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x17F5C7: bonobo_activation_internal_service_get_extended 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x17F6AB: bonobo_activation_service_get (in /usr/lib/libbonobo-
activation.so.4.0.0)
==28431==    by 0x1816A7: bonobo_activation_activation_context_get 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x1816C7: bonobo_activation_object_directory_get 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x17FF93: bonobo_activation_register_active_server_ext 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x180395: bonobo_activation_register_active_server 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x1805FF: bonobo_activation_active_server_register 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x8081F9D: panel_shell_register (in /usr/bin/gnome-panel.orig)
==28431==    by 0x806415F: main (in /usr/bin/gnome-panel.orig)
==28431== 
==28431== 
==28431== 112 bytes in 8 blocks are possibly lost in loss record 109 of 213
==28431==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==28431==    by 0x6D59FF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x38E73C7: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x38E6EC3: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x17FEC4: Bonobo_ActivationEnvValue_set (in /usr/lib/libbonobo-
activation.so.4.0.0)
==28431==    by 0x17EA65: bonobo_activation_init_activation_env 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==28431==    by 0x181958: bonobo_activation_orb_init (in /usr/lib/libbonobo-
activation.so.4.0.0)
==28431==    by 0x3B4DDBF: (within /usr/lib/libgnome-2.so.0.1000.0)
==28431==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==28431==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==28431==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==28431==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==28431== 
==28431== 
==28431== 136 bytes in 1 blocks are possibly lost in loss record 114 of 213
==28431==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==28431==    by 0x1B8F45B1: _dl_allocate_tls (in /lib/ld-2.3.5.so)
==28431==    by 0x46C541: pthread_create@@GLIBC_2.1 (in /lib/libpthread-
2.3.5.so)
==28431==    by 0x1F491D: (within /usr/lib/libgthread-2.0.so.0.600.4)
==28431==    by 0x6EB473: g_thread_create_full (in /usr/lib/libglib-
2.0.so.0.600.4)
==28431==    by 0x38FA68E: (within /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x38FA87B: link_exec_command (in /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x38FA92F: link_set_io_thread (in /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x38F5774: ORBit_ObjectAdaptor_set_thread_hintv 
(in /usr/lib/libORBit-2.so.0.0.0)
==28431==    by 0x393B7CD: bonobo_poa_get_threadedv (in /usr/lib/libbonobo-
2.so.0.0.0)
==28431==    by 0x393B920: bonobo_poa_get_threaded (in /usr/lib/libbonobo-
2.so.0.0.0)
==28431==    by 0x39CD62C: _gnome_vfs_get_client (in /usr/lib/libgnomevfs-
2.so.0.1000.0)
==28431==    by 0x39ED8C6: (within /usr/lib/libgnomevfs-2.so.0.1000.0)
==28431==    by 0x7833E0: g_type_class_ref (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431==    by 0x76BC1E: g_object_newv (in /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x76C033: g_object_new_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431==    by 0x76C1DB: g_object_new (in /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x39EE3D6: _gnome_vfs_get_volume_monitor_internal 
(in /usr/lib/libgnomevfs-2.so.0.1000.0)
==28431==    by 0x39EE3FF: gnome_vfs_get_volume_monitor 
(in /usr/lib/libgnomevfs-2.so.0.1000.0)
==28431==    by 0x808902C: (within /usr/bin/gnome-panel.orig)
==28431== 
==28431== 
==28431== 5912 bytes in 188 blocks are possibly lost in loss record 192 of 213
==28431==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==28431==    by 0x6D5A6D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
==28431==    by 0x77BB0A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x77D5CA: (within /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x77D7C3: g_type_init_with_debug_flags (in /usr/lib/libgobject-
2.0.so.0.600.4)
==28431==    by 0x77D921: g_type_init (in /usr/lib/libgobject-2.0.so.0.600.4)
==28431==    by 0x3B4B16D: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==28431==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==28431== 
==28431== LEAK SUMMARY:
==28431==    definitely lost: 44 bytes in 4 blocks.
==28431==      possibly lost: 6160 bytes in 197 blocks.
==28431==    still reachable: 2974486 bytes in 64002 blocks.
==28431==         suppressed: 0 bytes in 0 blocks.
==28431== Reachable blocks (those to which a pointer was found) are not shown.
==28431== To see them, rerun with: --show-reachable=yes
==25862== 
==25862== Syscall param write(buf) points to uninitialised byte(s)
==25862==    at 0x4710BB: (within /lib/libpthread-2.3.5.so)
==25862==    by 0x4A5550: _IceTransWrite (in /usr/X11R6/lib/libICE.so.6.3)
==25862==    by 0x49E496: _IceWrite (in /usr/X11R6/lib/libICE.so.6.3)
==25862==    by 0x49E56F: IceFlush (in /usr/X11R6/lib/libICE.so.6.3)
==25862==    by 0x48E52E: SmcRequestSaveYourself 
(in /usr/X11R6/lib/libSM.so.6.0)
==25862==    by 0x3BE12DA: gnome_client_request_save (in /usr/lib/libgnomeui-
2.so.0.1000.0)
==25862==    by 0x806BE9E: panel_session_request_logout (in /usr/bin/gnome-
panel.orig)
==25862==    by 0x8084179: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x771816: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x766284: g_closure_invoke (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x77478A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x775EDF: g_signal_emit_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x776253: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0xC608BC: gtk_widget_activate (in /usr/lib/libgtk-x11-
2.0.so.0.600.7)
==25862==    by 0xB93019: gtk_menu_shell_activate_item (in /usr/lib/libgtk-x11-
2.0.so.0.600.7)
==25862==    by 0xB932EC: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xB8A7FC: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0xB85351: (within /usr/lib/libgtk-x11-2.0.so.0.600.7)
==25862==    by 0x765D9A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x766284: g_closure_invoke (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==  Address 0x1B9CB555 is 13 bytes inside a block of size 1024 alloc'd
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x49B6E7: IceOpenConnection (in /usr/X11R6/lib/libICE.so.6.3)
==25862==    by 0x48EC47: SmcOpenConnection (in /usr/X11R6/lib/libSM.so.6.0)
==25862==    by 0x3BDF256: gnome_client_connect (in /usr/lib/libgnomeui-
2.so.0.1000.0)
==25862==    by 0x3BDF3CF: (within /usr/lib/libgnomeui-2.so.0.1000.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== ERROR SUMMARY: 200 errors from 11 contexts (suppressed: 129 from 4)
==25862== malloc/free: in use at exit: 2857567 bytes in 60282 blocks.
==25862== malloc/free: 547691 allocs, 487409 frees, 26580912 bytes allocated.
==25862== For counts of detected errors, rerun with: -v
==25862== searching for pointers to 60282 not-freed blocks.
==25862== checked 5422868 bytes.
==25862== 
==25862== 
==25862== 8 bytes in 1 blocks are definitely lost in loss record 19 of 195
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x6D5A6D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6CA729: (within /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6CAF05: g_key_file_get_string (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x5D45E3: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D535D: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D5DC9: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D5EC7: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D5E22: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D624D: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D7B3E: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5D7C38: menu_layout_node_menu_get_app_dirs 
(in /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5DA1A0: (within /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x5DB3F7: menu_tree_get_root_directory (in /usr/lib/libgnome-
menu.so.0.0.0)
==25862==    by 0x5DB5A7: menu_tree_get_directory_from_path 
(in /usr/lib/libgnome-menu.so.0.0.0)
==25862==    by 0x807C3A4: (within /usr/bin/gnome-panel.orig)
==25862==    by 0x771816: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x766284: g_closure_invoke (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x77478A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x775EDF: g_signal_emit_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862== 
==25862== 
==25862== 32 bytes in 2 blocks are definitely lost in loss record 58 of 195
==25862==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==25862==    by 0x6D59FF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x6E7C3A: g_strdup (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x3BDDF97: (within /usr/lib/libgnomeui-2.so.0.1000.0)
==25862==    by 0x116566: (within /usr/lib/libpopt.so.0.0.0)
==25862==    by 0x1165B8: (within /usr/lib/libpopt.so.0.0.0)
==25862==    by 0x117D7F: poptGetNextOpt (in /usr/lib/libpopt.so.0.0.0)
==25862==    by 0x3B4A231: gnome_program_parse_args (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE96: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== 
==25862== 112 bytes in 8 blocks are possibly lost in loss record 94 of 195
==25862==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==25862==    by 0x6D59FF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x38E73C7: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38E6EC3: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x17FEC4: Bonobo_ActivationEnvValue_set (in /usr/lib/libbonobo-
activation.so.4.0.0)
==25862==    by 0x17EA65: bonobo_activation_init_activation_env 
(in /usr/lib/libbonobo-activation.so.4.0.0)
==25862==    by 0x181958: bonobo_activation_orb_init (in /usr/lib/libbonobo-
activation.so.4.0.0)
==25862==    by 0x3B4DDBF: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4A549: gnome_program_postinit (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x3B4AE9E: (within /usr/lib/libgnome-2.so.0.1000.0)
==25862==    by 0x3B4B1AE: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== 
==25862== 136 bytes in 1 blocks are possibly lost in loss record 99 of 195
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x1B8F45B1: _dl_allocate_tls (in /lib/ld-2.3.5.so)
==25862==    by 0x46C541: pthread_create@@GLIBC_2.1 (in /lib/libpthread-
2.3.5.so)
==25862==    by 0x1F491D: (within /usr/lib/libgthread-2.0.so.0.600.4)
==25862==    by 0x6EB473: g_thread_create_full (in /usr/lib/libglib-
2.0.so.0.600.4)
==25862==    by 0x38FA68E: (within /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38FA87B: link_exec_command (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38FA92F: link_set_io_thread (in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x38F5774: ORBit_ObjectAdaptor_set_thread_hintv 
(in /usr/lib/libORBit-2.so.0.0.0)
==25862==    by 0x393B7CD: bonobo_poa_get_threadedv (in /usr/lib/libbonobo-
2.so.0.0.0)
==25862==    by 0x393B920: bonobo_poa_get_threaded (in /usr/lib/libbonobo-
2.so.0.0.0)
==25862==    by 0x39CD62C: _gnome_vfs_get_client (in /usr/lib/libgnomevfs-
2.so.0.1000.0)
==25862==    by 0x39ED8C6: (within /usr/lib/libgnomevfs-2.so.0.1000.0)
==25862==    by 0x7833E0: g_type_class_ref (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x76BC1E: g_object_newv (in /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x76C033: g_object_new_valist (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x76C1DB: g_object_new (in /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x39EE3D6: _gnome_vfs_get_volume_monitor_internal 
(in /usr/lib/libgnomevfs-2.so.0.1000.0)
==25862==    by 0x39EE3FF: gnome_vfs_get_volume_monitor 
(in /usr/lib/libgnomevfs-2.so.0.1000.0)
==25862==    by 0x808902C: (within /usr/bin/gnome-panel.orig)
==25862== 
==25862== 
==25862== 2600 bytes in 80 blocks are possibly lost in loss record 168 of 195
==25862==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==25862==    by 0x6D5A6D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
==25862==    by 0x77BB0A: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x77D5CA: (within /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x77D7C3: g_type_init_with_debug_flags (in /usr/lib/libgobject-
2.0.so.0.600.4)
==25862==    by 0x77D921: g_type_init (in /usr/lib/libgobject-2.0.so.0.600.4)
==25862==    by 0x3B4B16D: gnome_program_init (in /usr/lib/libgnome-
2.so.0.1000.0)
==25862==    by 0x806415A: main (in /usr/bin/gnome-panel.orig)
==25862== 
==25862== LEAK SUMMARY:
==25862==    definitely lost: 40 bytes in 3 blocks.
==25862==      possibly lost: 2848 bytes in 89 blocks.
==25862==    still reachable: 2854679 bytes in 60190 blocks.
==25862==         suppressed: 0 bytes in 0 blocks.
==25862== Reachable blocks (those to which a pointer was found) are not shown.
==25862== To see them, rerun with: --show-reachable=yes
===============END   VALGRIND SESSION======================================
Comment 10 John Saalwaechter 2005-07-11 10:09:57 EDT
The problem has returned with my account.  Not sure why it didn't happen for a 
few days.  Below is top output showing my gnome-panel at over 1GB!  I'll try 
again to capture this under valgrind.

===================TOP=======================================================
top - 09:04:38 up 9 days, 18:10,  2 users,  load average: 0.48, 0.92, 1.23
Tasks:  96 total,   2 running,  94 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3% us,  0.0% sy,  0.0% ni, 98.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    255572k total,   233452k used,    22120k free,     2392k buffers
Swap:   524280k total,   500576k used,    23704k free,    33948k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10603 myuser    16   0 1107m 230m 134m S  0.0 92.2   3:52.68 gnome-panel
 4585 root      16   0 90516  21m 3012 S  0.0  8.8   1990:57 X
10541 myuser    15   0 22500 7184 5620 S  0.0  2.8   0:00.90 gnome-session
10601 myuser    16   0 31076 5412 4488 S  0.0  2.1   0:02.88 nautilus
10613 myuser    16   0 22324 5172 4280 S  0.0  2.0   0:05.12 wnck-applet
10590 myuser    16   0 14168 4304 3676 S  0.0  1.7   0:06.09 metacity
 2414 ntp       15   0  4168 4168 3148 S  0.0  1.6   0:11.21 ntpd
10623 myuser    16   0 22696 4168 3588 S  0.0  1.6   0:09.49 clock-applet
10605 myuser    16   0 41808 3828 3572 S  0.0  1.5   0:00.59 eggcups
10625 myuser    16   0 20432 3640 3208 S  0.0  1.4   3:12.05 multiload-apple
10621 myuser    16   0 20564 3500 3100 S  0.0  1.4   0:00.24 notification-ar
10559 myuser    15   0 20952 3336 3092 S  0.0  1.3   0:03.38 gnome-settings-
10599 myuser    16   0 20632 3300 3124 S  0.0  1.3   0:00.20 gnome-volume-ma
10607 myuser    16   0 13120 2928 2632 S  0.0  1.1   0:01.34 pam-panel-icon
 2549 xfs       16   0  5568 2680 1128 S  0.0  1.0   0:04.72 xfs
14164 myuser    15   0  6236 2576 1236 S  0.0  1.0   0:00.50 csh
10616 myuser    17   0 12196 2492 2196 S  0.0  1.0   0:05.77 gnome-vfs-daemo
10572 myuser    16   0  4076 2312 1676 S  0.0  0.9   0:11.72 xscreensaver
10551 myuser    16   0 12240 1916 1520 S  0.0  0.7   0:02.03 gconfd-2
 4577 root      16   0 12132 1804 1804 S  0.0  0.7   0:00.16 gdm-binary
32224 myuser    16   0  3132 1796  932 S  1.3  0.7   7:12.73 gam_server
14156 root      16   0  3644 1780 1424 R  1.3  0.7   0:00.67 sshd2
===================TOP=======================================================
Comment 11 John Saalwaechter 2005-07-19 17:15:45 EDT
Here is valgrind output for gnome-panel for a session that I think included the 
memory leak.  I can't be certain because valgrind reserves a big chunk of 
memory up front, so its size is already large.

(bzip2'd and uuencoded to fit within a comment in bugzilla.)
===================CUT HERE===============================================
begin 644 gp-15065.log.bz2
M0EIH.3%!62936<`B@TP`A^-?@%(00.?_\G^_W^J____P8#;>``^WGPV7B[SF
ME;J^[9S=MUG4``!>"-J&*.P,X+#=!RM[==GP9AQV^CQ)YMJN#;N,$=G3C8D\
M!.I[T=W7/@```!>\Q2V*UM@R'R^]E>@`#0!T4H`(`"4D-`**```&0=\YV@``
M200$T"1`IZ0#:F0::`T>H'J`>B`2F@GE5)4:&C!,(R9`R,)A,$,@P0$J>]54
MDVD3TFIZF",!,`C3(,33$#(Q,!)ZJ20:IZI[*FF@!H````````1(FD(*:9JJ
M?HU('J:-/4R!D`:::`&0`I2@F@0!!`T(U&GJ8IZ:-1Z@QI-&&IDTJ(`]CY$.
MI`EI^NT/^B?W_0@R,/@M($55?P<M"<C1(1>*H(%\QJ6GFOHD%`XP,&2!>XU+
M2J[I!0,L-#)`O(U8<WL(H.\#$D@7N%0M-UM(*!O`P9(%[A4+3=;2"@;P,&2!
M>X5+#=?0(H.\#$D@7N%0M-UM(*!O`P9(%[A4+3=;2"@;P,&2!>X5+#=;"*#O
M`Q)(%[C4M-UM(HAO`P9(%[C4M-UM(HAO`P9(%[C5AN]A%!W@8DD"]QJ6G5=)
M!0-X&#)`O<*A:<UM(HAO`P9(%[A4L-UL(H.\#$D@7N%0M-UM(*!O`P9(%[@5
M:48D%`S3H9(%YLVJ07UQ2Q4@L@A;OE3M)>I<"7Q"YCX]?W;X?Y_H-\/^P,3:
M@+U`MOLA(H48<TTIN)IS33F9S33FFG,RUS6N:FXFEKFYF<TTI^'?V^'_E]O6
M]Z\?"\O``````[7:'EQ7%YKIQNEQ=.-TN+IQNEQ=.-TN+IQNEQ=.-TN+IQNE
MQ=.-TN+IQQ%=+I=.-TN+IQQ72Z73C=+BZ.RAAV(9Y&'!A<Z,Y-F/\'6DLT"#
MP]'X%UZ]G9L-AMX^G3IL-AL-AL-M:UH;=.G3IMK0V&QU[NSIO,\?*JW?Y@\;
M-?=W=_^-]"\<19,98=B@.#A#(@(!PB!991<"PL*"XEA84%P++*+@6%A07$L+
M"@N!991<"QL:&XMC8T-P;+*+@6%A07$L;&AN#98Y#!`0#A#!5IK6*U<YY[^)
M7ZX0"KMTS,P``>5WK5[^M7G96M\-JU;TA4F(V>I1=(+1-&C`AEA0PRDJ<EO5
M;7;M6W":&4P@OWR:_;#6M`%%"T$;9O1:-L24L`(E*51'47@`TZX+0*U4H`B/
MS6N*JZJ5;KF_V`!UKG`6Z:#G[BM2220AQAQPG5J3JGA>KTIL0H'@<.82`XIV
M$.:>.<2HIJM<J7DH"53=KBUVA`;/!Q7*[7C5=6\)J41H6!ERI]PE@AN$/QD1
M#1_F:++Q91HEW:(Y/XH_P1V<F]3=H=60K"-O:(&<@\'Y_<NQ`_S?*>[Z?=21
M_I&K6\Z/E,U3[$8H\4?%_LFB._?*L&9#OBX3,D</\[@#,N:<_>]N([9YF99J
M3-HNUZ4M9FKN_&\OEW9.7N[CE\;OMY7N]G+N[<2[=[>6FNLZF\SKC4K6K-0N
M]9DK6NV]S,R^87?'H4$\$!:F,1>\OK8A3;3"!CM(5!!9BX889`EY-J;VGOCY
MG+XF'BWJ'\@#XDWY)*_E1V,^*H^%!)U1BH=:%?*\667+6W8E/7BMMFGA)?)&
MP<<OZ$><+[T:>,N]U%SO=[^'EN'J3XH[OO?)'Z?'LC[?=?!=_+3Q]_3XAI[\
MO1:M[&C,1>#-R\F,)JX`-@0D`R2J?"(E"'=[\)))#M5$C"5$.Y`G";NC^W^G
M/[OX:_GW@^;VDGU1#5)?80_*?=@7K/:?((/7Y>&]GJ/3,O[/31K/+^LI>[,\
MS2*S-XKS?IIYEXLR]R\W=S#W9"_C8SSS-V\6Y=9(:;1AFI+XM0;V"#S%[1#_
M/V(2^0]8>8@\T?>;^ZC;1NCJNDD_"1\T?)'9'X!SB_5S.R/^'5&C#$;N9]U'
MZ./F(:$-(AT[FC\G(Q_0?>BEL4%5DPC]F%%=CZ9';PGUK\&M^&<MDS+,5$:&
M!)^T06H!HA4;=#^Z9"LP2(;A3AL;LAHB\L!M"@;HJI5C!H!JQD61T%7(LDNB
MM(R$C-%&%KAA0!HK"%&:<)J516D9"1F%&%KAA0!HK"%&:<)--:1D)`T4.M4)
MHJZLJ%U5$M&0D9A1A:X84`:*PA1FG":JJ)I&0D9A1A:X84`:*PA1FG"336D9
M"0F486&90FBLE6:EU5$M&0D9HHPM<,*`-%80HS3A-55$TC(2,PHPM<,*`-%8
M0HS3A)IK2,A(3*,+#,H3162K-2Y15A<)&&FC"T,<:%-&-M9I,9J45H+A(PQH
MPM#'&A31C;6:3&336D9"0-%#K5":*NK*A<JBK1D)&8486N&%`&BL(49IPFJJ
M5H+A(PQHPM#'&A31C;6:3&336D9"0F486&90FBLE6:EU5$M&0D9HHPM<,*`-
M%80HS3A-$C-`ZW5R09&0JJ$A"RAU!MJ-?B/0A]BB?J^U\MHQC&`,%C)?3GU<
M/@C>C\U^"_L7LCZU-EV_=&,;=^57&6%(EJ-D2U%D2T:$2U&R):BR)J+(EJ-D
M2U%D346$VL:A-K%2):-"):C83:Q4B:BR):C9DKFBTR_(2UGUX9DU1[XS^;11
MHT[OKTL5FF@TTT"8RS&?D*]D>OU<(+[G`KHCU:*<U,BI_8CS1ZT?$0_LGY#[
MOF'X3U^*_K5+<N.0+EQ:E1:E1:E-N.-N.-N.-N.-N.-N.-N.-N.,U*BU*BU*
M@U*A]A^O^G[`'\`D48>JD'7+-5;7TD%6-IHL!HL!HL;%@-%@-%C8L!HL!HL8
M$!-%C8L`":+&Q8#19L4SY4JE\R1-$:I5O&H5L*T-*M4D,U)+]%65:I53CI53
MZ/**GWU?6Z*9C]=,>#&,,8PI)*22DDI*N;2UMN]B)@KS06(_DWC_T?01=R.4
M5/QGV3U-TK*8(M&52E@Q34$C2J)/V7*J:4WRM?;1'T/K9OF]-TB0HUB*\M,>
M"RNQ4O7T`D#JHX*N2VDUI-:2VDUI-:2VDUI*R5DK2:TFLE:36DVU)MVEK(P6
MPM+0UF2;9DFV8ELR3;,DVS$MF2;9DFV8FF2:9);,2V9)9DELQ+9DLDR93+&9
M$K$D,1$P2Q$3MNUI5S1$Z:I5D:<DAE#WV3K-FA$=X:%T'$34#4?RT69-+^,U
MLL3I5'D7?7.!XS@I5'Q?.85HZI+,G`B.MRE!*3_$X4V+;Q2(%;AH8P%1.VL$
M1G(B.;JP6$/4%?S;WQ-"\C*ASR%%YI$.T69VP1'8#@EA?O5SZ.KLZ,*YEW4Q
MAEDS&9$1$1$1$1$1$1`DE)HDI2REDI)2REB(B2B3)$!)DT&(,0!B(B&1DDD.
MCH]A#L8W9T"^ZJ"I[E=BU)=;QMLBJZL;&U\78JS69\%@$+(@^42'09`[$AH1
M6':/45U)$3L0#WA>"(]"([=7^$!']2%IJ('RBNCIJITJC':!6OEOQ^A'@?",
M^(_E1""W#J&[IZ4G201/>'),F\];S#X'\P*B5VCW'WI`X$3F"T_'51&%W]-&
MG(`;``R#:XKX(WO3FXKH2Q6WI+3;V2;8J-'EH5[@8J>.W%P>R2_:KPUG?"7>
M*!%4;H6"$4INE]MOU%A['D$M#Q1X>!2\WDX%M\]4EJJQ:;.7(6C(5(X$K"7@
MY0&Y=(-SA"M<CE`5YFY-N=\]]$QT5ZJ$0`SJ[)2L5))2^^E1R6%7+XHB?S:A
M6A(>G&.XU8?"J/5>&'G[1$?EA\D7;OB#\L$/KQWWSBCBG+O1/+1Q(XRG?M+W
MY]TEZ=.??OO6#UG(A"<22\G2!'H+7;<SM<HD",KCO>R<G(K[\[T>!$=P1'L@
M!4SYYV4$^F9KOP[ZZ4$U]F=S9P>J1#I3@2`]`T4)..&VVPVV&VVVVP```;0)
MQ))(VG$I<2EPG"<2EQ*7``$D;3A.$V$3A.#9``#+```#9`[+MNJUXIW;6L8Y
M$!6_)IM,R9H=V:MF;4%4C0Z1M;"I-L/A(E">(NSIVP3CT)!-Z2)!R(0KZA#,
MTBJ;T4JCOO..]GCZJ;51Z\]^\TH)'2FA$:ZKA2I._3\!H2%T/3HERY8B,>">
MB5T<AUN\J:+.%.2+8%:]M[%\\H(V=;G')AI5'@T[Z<-U9"^.Y\Q*UXIVYK38
MZJWS1+T<(]E=%="Z.ZJ\6GHX1N\5W/));/@RKPX*RJ78Q8RT1@KKX.L'9L[>
M[E=M'#H+SKMO!;R^+;;:\TV[S;8#O>3P]?!W=CIW/*['=QLG*G''6^;G+FJ_
M8$7B*LBK(*2*IML5HVV-MBM&K1JT6U(JR()("2*LB)(B(Q[N=^"POMT`O/6N
M]ZZY-B(VCAG(!(;CSLN:51HXNFS%-S)KCN/D?F4@&@W%\3J^:@>CI&8-LSR>
M"U.*5O/:P,9=G7!@0'$YM;/?/1-MC<ZZ-ZF,@%$D67@JV.!!!L@`QSPDD)@0
M7:W>B!`&_):!!V=<)'8*F^_#>_+=ULEIDR`C9\*Z.YVUSM3!`4H??+^$D4X$
M1\.ALG.(>*$1UW\;I01R^BTVV2()Z-A+<W$DMZ-N2>!@>J2,0D/LYMIS@G;B
MM;MV0D"-`$X;8GF1\)`FB-=<>.CH\I&ZSKQ=T;*Y2W(]'=)XM5RYJVU1ZAM0
MZM%J<F.P#8O0O9.%+=<G>9XV4`<&&\S"#USBDN7%4\)+ZDE:B0V)$"!&"N>L
MDY;RQVJO+C;V*XVW\GDJNK=!VV>+HY[I+>DNRA9L28-7H^-`)2R%EGJ]:UC"
M0(=YT(9RH9:KCC:!K[I+'&VA4G*K'4P=>;Z\\7[+TU2FXEP06BD:$(6:%W[,
M(`/7W_#;7O5F2LRV8Q86#:#`&#:@#4;!L&J-@```V#9)-C&P!C&,`&PFV2BM
MLD%HB0Q%1%$`=K;-5>EXXV[NV.RL>ZW;JVU'EE4:/(@D07*=U(&21VD'%,MO
MLUV%#$LC"ZL\QK7%LXXWZ`1W\'I5'Y@\"0A&$DDD@`````LDPDI*22R4@!(1
MC$3(20P```].UWW;SJJ]00JFIV9[(SE($4Y/!FIBD;&02Y$%GHW(JH`GC%"4
MDIPYO6&=D"5DB:9P0`!B]DB!)*A'0(%1W%BT3(`%7<`#@EQ))-%92!$@(+DN
M3!R<;&R24B6U]KRVM[G9'+B#+["4`EK-4@I0\*1%P3#"91BP``P9)),EDL8R
M62P`DF,1&,2`!`!(![O@EU::$[.*O`KJ]&BN1&Y6FB.16B"&!*M!)3F0`WE^
M>P!EJ8UFAP3:]F*`'H5[[RNC;.W;C0M7T"0G$M5Q`EX0@+,"+R=3E1&:P%37
M5"$%G?-'N&J]R#K,Q<LO(0A5O:I'@R+C!QF*E*07-T`#=/N4VFI3DMO#\($*
MX937W(KDC=[Z\&+25N;CQ]:W>TDR``````!9)A)24DEDI`"0C&(F0DA2"222
M0A)*!P\"U\SOK!"'8[*";M58Z*!+";IP09,$7H4&&)!@,EA;"5="3<;L\M8%
MEL;H4,_98WAJ:K9]K#C[-FFZ$#L"2TB&V><DI`TM:*5-Q!PA!&[\E0`W`[RI
MN'F>A;#P6`^<H\]Z]MTJC\YQ[<X.@(I`D!/8>PM)+`,KSH)PH(<QUKJE$XL)
M$<=)!S7,/J'B[Z&JQ,"U%;9H.PO"1MH`=(F2]#HY-[I(;;<%T)$5Q*3CDX0A
M"$(0A"$(0A"$(0@"22DE+-$I*7%*7%)222EQ2EQ1"$(E(B2RTB`$3B3BTP:V
M;836S&!H3+0A-B9MFV9GENWG*NRN>.U<=50')=:+8!="3V.TD<-47*$'V""+
M6*MDYC'&!2+<$T\2SYNW`E)P9,ZP[\W$[,S,S````'IY=7.<N<Y<YR.<Y<XX
MS.[.F=G3.X[LZ=G=SG&+]1?BL5K6*UI:AF]VZ62R62DLFC26319E3-DI-F6-
M)MY7KZWNZ=>%MO'P_C(_-'[J?T)@Q8R699/<-4S255U541($4^\C9$"!T(>A
M#X._OHB.SS>[7EL]WOY_!QQ[O:W>C97@KQ5PC4KLC16JME=%=7N\>Y+DNP'E
M`T77;,NKCX=I&A'9P\W=HJMP,>?=]P!BAL('$%Q@.BF2#.3DMFU`LP,P````
M#OZ;:\[RMM[=]J\'!>SQ[B&`N^#DY[L)&'B4,N$A(21$1%B*(-ZZU?%O*O6M
MO:WX+7%<>3G3SIX]^O^37]$%]:`#RJ>J'H6%U30O,NB>Q86J;"]2C^0*E54*
MX1Q9!D$8:$(0JH!U*N+J4R4JPTJ$J4!*Y=<=XVW7+K;O&VZY=;=XVQURZVXL
MTDDKEUQWC;=<NMN\;8ZY=;<6:225RZX[QMNN76W>-MURZV[QMNN76W>-MURZ
MV[QMCKEUMQ9I)**)7+KCBS22$KEUQQ9I)`HJ5RZXXLTD@$KEUQQ9I)"5RZXX
MLTD@$KEUQQ9I)"5RZXXLTD@5#DI)!YF>/*[]O+2-@Q&V,\Z5;0V0**A4$<60
M9!&&A"$"%<(XL@R",-"$(!.NZM=<=XVP&5PCK&.4JPVB0@0HX$'%A`9"D5AI
M1"!"B%'`@XL(#(4BL-*(0(0KA'60<I5AM$A"!PCK(.4JVB0@0H@(.+"`R%(K
M#2B$"5"C@0<6$!D*16&E$($E<NN.+-)(2N77'%FDD)7+KCBS22$KEUQQ9I)"
MB%<(XL@R",-"$)4KEUQWC;JJ8<(ZQCE*MHD&X6%B.L@Y2K:)!TUMOUY[T**&
M<DY(/QY+WO>/-TUMOS$9M2.C1&V,\Z59M#9)1PCK(.4JS:)"443EWL]I:4G>
M)!C2;;'[V;-T3[GMNV_$K<SW::E)WB0=-;;\UFDDHJ=WO)]R%%?B0MSO).=O
MB9;A/>N>D]B>[[>=X[U&)6L[R[B/'"KM=<>R[WB25U<NN.+-))02N77'%FDD
MJ5RZXXLTDE"1T\O7-G<2_.[$^;VY<?B%QQ,WPY#N7*Q3'-MW'XAN"FN;<F<U
M#\-```'S@H_R?#R[EV>[U[:9CW;]WFY<RMA85\$<GP""!^1*#N`LD'9QP<'B
M2Q&84$1!!$055%EW99=W=W99=V67=W=VVW=MMW95467=MMW=W=EEW55Y/)%?
M'MY$36=]HNU>'"^R$X>+FKN7DY[B\A=BN3D[<(U?S?F1U1^2/L?>G+QW1ZO%
M'JP6JKS]WJW7B]?0O06F$F]KHSC"6[2SNOJ8#S1R*#A10=G@]"]CZ%8*^#/;
M?*.3]"-T:JO.\>'Q\'^;LM#PYN79'8D]D=OT-T</%HO%[(RAV:4:O36]C!?E
MZ.#!#T+R+\![^YX]#*7J2$F=<89.,^=M`)6)$%MQ*#XE=Q`L#));FU@87P-%
M<^WNC_5T:7[&.`//Q[=W7&/55HKS:XR1OB3P1J-W@T-:I[NCP6J.B]G*AR].
MG5M[9GJS9VW(^+$:J\D+"N<Z$X1D8T((-)&#0@]'+*K./T@'D!IV>@'L]GH=
MN;V*ZZ.SQ;Z'KWV>`UK"JRA#X@AHYBORH]BQL!OMARJ4./5KR)9W1\G]J.KH
MQ&>R/)UXYNVP`<*\\]B#VGD(.2:GD).YN/),G9RYOP)HU0MGCH7K!<]>A#[`
M7OM`,%>_(O*LD;`:-'J]5<O`\<.,<C;'AX4U1LQ7"O61Y-E]/U^]'^K\&AH^
MFWS?M/N`;OH_!]KHT8/@C_9_NU1^IL[.;F1\W1_F1S_0?H=7IJ_F`V1^"/5*
MX2Z'P_/X.O9Q\$?A5BBZ/9W1]$:$;-@C&?S'F9.RH(.3CWD`=C"#OH]AD$$W
M``/@('/?9C2#ZTE4H#>8(+D%OJ_7N>\0<.3Y/N>KZG<#^X#E?<!F^O\G4K_H
MK9&B@\2M5>VR.3'G?P?X*O_.$V?6!C=S5=%:M>PS>!]SDWXTJZ'\4;&KA:(_
MDSEM3#N5Y75&BJNS=+ONVUSG6YS_-UN5M<UXK;H``````/-O)=+I:J[KG-7V
M5V5WUX9T7DX5X/M1_BDZH\6Z,:(Y<VRO&[:JO*OB7.]RV\;O)))"208QC"$8
MR0AY+.C8CP70]=NE0M6F$:TT`\^6C=D[.'E3%PKFMW)N;([<V.[V.7ARWJ9_
MEP71!\?1JKJG:*^1\JJ?0YUI^<\EEF@4H7E6A#9S>'1NK%5<S=I)T1J_I1S-
M6/BNBI44F`@2#&:<LDDFJ)PV&$$Z\Q)9-79&K"-UZ.L%T4O0Y/\4%H4KH6U5
MXJY(Y\XC5VNCJ!H4/QK^4Q!GI7!WQ(T)<&B*:DT(W_-'D(X<FYAT>]%7@K'*
MZ/FU/)'LZ5%O;70#S4W1RHZICJ_T271'/QW,O(G?9JU4Q2+[%S)/G^G')J\6
M(]WV^T4DS*>R-31(O%BI2_**GR12_K83A5;RE;BM553Z*%JHF-&L']]\WNC*
M+X223BBKD@<.&B*?TP7DYNK9'1Z+I):DYJ;`?F:%<H+;[17V;(V4N3KS1R*]
M4=G1,QS5:(TD5Q2KY@;M'W,?>JR'1'$DQ&AXKFC8E#N(OP1A2M"/]TTEX9FJ
M#M4L`(0@+10"446/D=%$L0PL^I))F,UV4L-:QP^K$X3H[(Y.2L:+O5/@C/(5
MA.-ERI-:3`T@9Y(TM+[DS1'E5X/:?BT7TT@:ZK_D/5T3ZGP1JCI5.F?@P5S1
MLW1HNE],/JHJ:[IC%D8P6(U?4=.+YN&JW;J\W-HK'-P1U@<O16R.55-@/%Y=
MCJQ!W[JZL*\$='F;.2_J1V*8R3FCO1[-3P1_B]9-9)XXI/^!%=D:VH:>6B.`
MZO"((@B$R8),%:^"QH<D=VFB,(W<BT1B4TJ&*'.BK*->L-T&(\6A7[_BJK7D
MNKX,8N;A6G)L^27"&J.W."^-U<XO/;>P````2U)28K.Y6@?DU#VD8C>1X*OR
M8D\?U(W*EY(Q'@*X3XY(X^27S,8QC&,8S,9,8WI?;Y%JQ&,'!/5=+!\*O%IH
M]G1&*_;RJT5B/F^?F_"I7E=%6J]VKYJ;.SJX+B!JUHRHQ87ZB/O1HI:OFK'%
M)SBIC&T!HCHC2JF]5,E4^]&%D9'XJX2>V(N;FW=E#A2ME58E3M%38AR8QJ!7
M?3*#Q^79&\%RBL9U5L^+YBLF>S$94M%HI8!LZILVDVAHC0K^I&DI31&S0FQ&
M5/F]1LK5=U44;BL@YO=3V*^U&Q&Z=M$N%.\5.&-U;;E5U:O;J[\MJO/[-AAL
M8V-3+95EMMB,DE@MJ-16*Q6*Q6*Q6*Q:BL;8K%8K)2FM2&MM$;-E00000000
M0000000003;;";"4HQHBS),:2RE)4EE*39))-DLI25)92DL9)-DLI25)92DL
M9)*F:EEDVF:EEDU)))LEE*34S4LLE1DDV2RE)68DS2F3)B3)B3)C,TRLQC#+
M#,8QC*GDHCSBILZ:TGZ0[^;P;H^C'@[(\/J;(^SU)R6`B(B(B(B(B(@J]('I
M-.L\4^!-0Q3LV:Q'#MBJ+,#P?4`YIPXGOM_6P-0UXVU7I;6O=BC&*,8HQBQH
MQ1HQF_C:V^M:ERU*TL-0-$>8R!X\RM;V(ELM</%0KT>8=_B(KT^IURG`Z6&8
M9869*9@CII,:1IJU:-<]JAL%W9(KJ*U7R[8S+%,?;%31H!."P6Q5:M+80&"V
M+2M?:@#\A.BNC!7@5LC1]D^UYBL5BZ4=F=OM?%2N"(CFR#LJW6):NT^YM-59
M0<,.R,=,F!DI38O%*3NFCFTH5JC4:JI=(#T<^BYT>9_>]/3V>`>.9#$9*RZA
MH&F,AU:<R.DT)B3"LT94^CPD/&Y>YI(UD953",JGR6`:/P=.DE3S,$?)OR]U
M,M&,-E>+X%5L:#5R#Z.</"+J(,BNR@U95!<-]))F(UD:*?-&(+6*FYH4:M=%
M:O"FB/XJQ4VUII"N[/FJK17,DZ+$<M'-C%:4+NRK@>@M05[H&`!I5<-"[(7I
M,4EL9,4%NYTBO!1XJ<7-PF)8I<0<T:+5#&(_<C]:UJ'P)]'_5&BGG5\E"Q2(
MP5-WS/L+S12]">H"U2D]LH#1[5*U+7*#_MQ$_&H>RPV4<4BOFNUTQ0/%5BI8
MQ)E&=F!_;NJQ]ALUU9Y*%^*,$FD'E79T%>'5T/%=6[[T<::>'WDUG".TD\?W
M14^G0CDVP/R1Y23P%9$,J9`>JCS8I_!ZO%'@C7X_UN]=D?T8C[Q-;L*T4\&:
M7XQ4]P/>^S&-^JCD_>8_';DT@N2,T.$9BGI9HQ1_-&E3]+@C3N1DM\0=>IS&
MS;AL=%\<E/M6J31&,=ZHDTT2;,JPT:%,8]?V9P8@^/XW)&R.&DDT:595-,%>
M4!W1ZH]VBR3Y&DD\15U4NAB-EB/*0MY'Q3VD=KO%3X/+JH_]GVUOJ]@YA.ZC
MN^V1M(\G"-$8CO>N`=,4XW"MZ,1]K/#HQ'"/UHZODF#DC62:.J.$;1%R1Z<2
M39&I^<W]UC)AF3,0P]/"U>U7;TL;&QL;&QL;&QL;&QL;&QL;%OH;OVLO;5[K
M0_6]4>J.MI\4<_2CUFA&J-^<%RN2:@:P^:-T<A79-E5<G_?IOR#R%<C13\9$
MC?5B.U42;IWDF=&2-!6-@FD0TON4U4/VHVJ>/-=65+,6?_D?%&Z``@^V7-<:
MAWZ;PQ,O+2Q,O+2Q,O+2Q,WJU&[>K4;MZM1NWJU&[>K4:DEMZM1NWJU&I;>K
M4;MZM1NWJU&_0!4`'T>/8RE-*4E*:4I*4TI24LV662E-++)2F"^SU27#$;23
MN3@0.25HCE6`:`(04&F>^-XQ!0(0(B!B&5RT5BMF@='&ZZMZW;<S08!AB/):
M:J=MIF7Q-(VHYHT1LJG57/@K$8DRAMQ*5O:P:M*EXDR4ICR1U?8\DT,PW7DI
MU1S94[M"DLVQ0KBE')H'1)]=%]8KDV8ZM$=!<&1/%'@IYT6J]U-6ZC/%D'@K
M_EX+VHT/E4Y/=?\OM>ZX/X>"C4DX1\*Q'T1\5E7P\5,]/51.7"->U^^J)-KS
MHO9]]'J[.[9'N_!OJCOB[H-/J*B].^8M$GU^P;,5<QPMJJ:RN=0U-I<48<R-
M62,1RE*;(X;[;F9HYOF\1+_[2)-V*JW)_HQ5>W1CP>M22:M-:0V:ZAE7^J,>
5RCXOX'R=(5>4/_XNY(IPH2&`10:8
`
end
===================CUT HERE===============================================
Comment 12 Mark McLoughlin 2005-07-20 04:59:44 EDT
 - Dude, "Create a New Attachment"

 - Have you updated to gnome-panel-2.10.1-10.1?

 - I'm getting totally lost on the details here. When exactly do you see the
   10M jumps in memory? Is it when you launch a program from the menus or
   a launcher?
Comment 13 Erwin Rol 2005-07-20 05:08:28 EDT
(In reply to comment #3)
> Mark, I created some confusion.  The original reporter of this bug may be 
> running an x86_64 machine based his web browser User-Agent info above. 

The original poster (me) _is_ running x86_64 in 64bit mode, i have no FC4 i386
install at the moment to verify if it has the same problem.

- Erwin
Comment 14 Erwin Rol 2005-07-20 05:15:14 EDT
(In reply to comment #6)

> So, to the original reporter Erwin - do you still see this bug with FC4? If so,
> then:
> 
>   - Was it a clean install of FC4?

Hmmm nope, it was a beta that got updated.

>   - Is this an x86-64 machine?

Yes, and it is running in 64bit mode.

>   - Is this with a long running session or do you see the 10M jumps as soon
>     as you log in?

As soon as i login, but only if i open for example a PDF docuemtn, the memory
does not grow "on its own". For everytime i open a PDF (but not just PDF)
document the memory useage grows, until it fills my 2G RAM and 4G swap.

>   - Does removing ~/.gnome2/session, logging out and back in again help?

Hmmm will try (after i finished this comment)

>   - Anything unusual about your system?

It runs Linux ;-) But it has no weird software installed. 
Comment 15 Erwin Rol 2005-07-20 05:16:46 EDT
(In reply to comment #8)
> Okay:
> 
>   - Was it a clean install of FC4?
>   - Does removing ~/.gnome2/session, logging out and back in again help?
>   - Anything unusual about your system?
> 
> Try running the panel under valgrind for a long period:
> 
>   $> gnome-session-remove gnome-panel
>   $> GNOME_PANEL_DEBUG=1 valgrind --tool=memcheck --leak-check=yes
> --num-callers=20 gnome-panel > t.log 2>&1

AFAIK valgrind doesn't work on x86_64 ? or did i missunderstood something ?

Comment 16 Mark McLoughlin 2005-07-20 05:36:58 EDT
Thanks Erwin:

(In reply to comment #14)

> >   - Is this with a long running session or do you see the 10M jumps as soon
> >     as you log in?
> 
> As soon as i login, but only if i open for example a PDF docuemtn, the memory
> does not grow "on its own". For everytime i open a PDF (but not just PDF)
> document the memory useage grows, until it fills my 2G RAM and 4G swap.

How exactly are you opening the PDF document?

Have you updated to gnome-panel-2.10.1-10.1 ?

Comment 17 Erwin Rol 2005-07-20 05:50:12 EDT
(In reply to comment #16)
> Thanks Erwin:
> 
> (In reply to comment #14)
> 
> > >   - Is this with a long running session or do you see the 10M jumps as soon
> > >     as you log in?
> > 
> > As soon as i login, but only if i open for example a PDF docuemtn, the memory
> > does not grow "on its own". For everytime i open a PDF (but not just PDF)
> > document the memory useage grows, until it fills my 2G RAM and 4G swap.
> 
> How exactly are you opening the PDF document?
> 

As described in the original bug report, simply by clicking on a PDF in
nautilus. But the memory leak also happens when opening files from programms
directly. There was a sugestion that it might have to do with the
most-resently-used list in the panel.

> Have you updated to gnome-panel-2.10.1-10.1 ?

Yes.

> 
> 

A (nasty) workaround i have now is that i just kill the panel and than
gnome-session (?) restarts it automatically. After that the memory use is normal
again, but starts to grow as soon as you open documents again.

Comment 18 Erwin Rol 2005-07-20 06:47:08 EDT
Created attachment 116969 [details]
valgrind log

Her a log of the last (alpha) valgrind for AMD64. Since the AMD64 support isn't
readdy yet the log might not be 100% correct, but maybe it helps.
- Erwin
Comment 19 Erwin Rol 2005-07-20 07:42:23 EDT
After looking into it a bit more it seems that there is a difference in memory
growth at the start. When the RU list is empty the memory use doesn't grow as
fast, but as soon as the list is full it starts growing with ~4Mb for every
opened file. 

This might not have been the case in the attached valgrind log, so i will make a
new one later.

- Erwin
Comment 20 John Saalwaechter 2005-07-20 10:35:36 EDT
Created attachment 116978 [details]
gnome-panel valgrind from i386

This valgrind session may capture the gnome-panel memory leak.
Comment 21 John Saalwaechter 2005-07-20 10:50:06 EDT
(In reply to comment #12)
>  - Dude, "Create a New Attachment"

Sorry about that -- lesson learned.  Text attachment of the valgrind log just 
added.

>  - I'm getting totally lost on the details here. When exactly do you see the
>    10M jumps in memory? Is it when you launch a program from the menus or
>    a launcher?

OK, let me start from scratch with an explanation of the behavior I've observed.

* New install of FC4 on single-cpu Pentium 4 desktop (model name : Intel(R)
Pentium(R) 4 CPU 1500MHz)
* "Everything" install
* Login as normal user, change desktop background 
from /usr/share/backgrounds/images/default.png 
to /usr/share/backgrounds/images/tiny_blast_of_red.jpg
* Let system sit pretty much idle running xscreensaver for a day or two
* About 75% of the time in this situation gnome-panel will have grown to 
consume most or all memory (see comment #10 in this bug report)
* As part of troubleshooting, I also witnessed the behavior Erwin originally 
described (opening/closing PDFs caused gnome-panel to jump by several MBs)

The main "unusual" thing about my desktop is that it's part of a network that 
uses NIS and has NFS-mounted home directories.

(I needed a stable system in the short term for some project work, so I 
downgraded to FC3 for now. I can switch back to FC4 on this system next week.)
Comment 22 Erwin Rol 2005-07-20 21:28:24 EDT
Created attachment 117000 [details]
backport of panel 2.11.4

The patch is a backport of some RU-list fixes in 2.11.4.
Now the memory usage seems to be stable, atleast i didn't see a change in
memory usage when opening a lot of files that filled up the RU-list.

- Erwin
Comment 23 Mark McLoughlin 2005-07-26 09:40:07 EDT
Thanks, I've pulled out the bits which should fix the leaks you're seeing. I'll
push an FC-4 update with the fix soon:

* Tue Jul 26 2005 Mark McLoughlin <markmc@redhat.com> 2.10.1-10.2
- Backport fix for recent-files memory leak - thanks to Erwin Rol
  for tracking this down (rh #160137)


Jorn: it sounds like your bug is different. After testing 2.10.1-10.2, if you
still see your problem, please open a new bug.
Comment 24 Mark McLoughlin 2005-07-26 12:06:17 EDT
Okay, the gnome-panel-2.10.1-10.2 update has been released now
Comment 25 John Saalwaechter 2005-08-12 15:10:26 EDT
(In reply to comment #23)
> John: it sounds like your bug is different. After testing 2.10.1-10.2, if you
> still see your problem, please open a new bug.

I reinstalled FC4 and updated to gnome-panel-2.10.1-10.2.  Things have been 
fine for over a week now, with no memory growth of gnome-panel.  This update 
appears to have fixed the problem I was having.

Note You need to log in before you can comment on or make changes to this bug.