Bugzilla – Bug 78329
wnck-applet Consumes Much Memory (atk/gail leaks)
Last modified: 2007-11-02 15:52:59 UTC
Please check whether wnck-applet leaks memory; on my workstation 'top' says: 18602 ke 16 0 158m 68m 4776 D 1.3 13.5 15:21.47 wnck-applet (BTW, what is wnck-applet? I'm inclined to disable it, if it isn't essential.)
An easy way to test what wnck-applet does in GNOME is simply to kill it. In this case, it runs the following (vital) applets: Window Selector Show Desktop Window List Workspace Switcher But it does sound like it has a leak somewhere.
thanks for the info - my machine is good for detecting those issues: 512MB RAM and I use to run my X session from SL version to SL version without restarted (modulo power supply issues...). This morning I updated from beta3 to SL 9.3-final; ATM, it looks as follows: 17574 ke 16 0 20600 12m 8356 S 0.3 2.4 0:09.79 wnck-applet
By your last entry, I assume it no longer uses lots of memory?
Maybe, it is fixed in the meantime - the low consumption of 12m was just observed after starting a GNOME session. In the next two weeks I probably cannot tesst it.
Next week I update my workstation.
Still no good. uptime 10:36am up 24 days 21:42, 14 users, load average: 2.38, 1.40, 0.88 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6725 ke 16 0 131m 85m 9144 S 0.7 8.4 2:45.99 wnck-applet
[Changing product for making the bug public.]
I've had this happen as well. At first it was because I ran ssh-add in the session startup (I don't do that anymore). I can recreate the problem by running gftp (gftp-2.0.16-45.6).
Another wnck related issue.
John: you saw ssh-add make wnck-applet use lots of memory or lots of CPU? If the latter, that's already been fixed and the fix will be going out to SUSE 10.0 soonish. If the former, does just starting gftp cause the problem or do you have to do something inside gftp first? Karl: of the four applets Ben mentioned that are part of wnck-applet, which ones do you have on your panel? "Window Selector" is the icon (normally on the right edge of the top panel) showing the icon of the active window, which you can also click on to select another window. "Show Desktop" is the icon of the desktop, which hides all windows. "Window List" is the grid showing window names and icons that you can click on to raise or iconify windows. "Workspace Switcher" is the 2x2 grid showing a zoomed out picture of the desktop and allowing you to switch to other desktops. I think all of them are present in the default panel configuration, so if you haven't changed anything, you probably have all of them. Also, of the applets that are visible, which ones do you actually use regularly? (Eg, I have the "Show Desktop" button in my panel, but I almost never click on it, etc.)
My system is up and running since 92 days: 9:54am up 92 days 16:56, 15 users, load average: 0.28, 0.36, 0.39 Strange enough, X thinks it is already running since 3066 hours (=127 days?). Might be another bug. Here is the top output; wnck-applet eats 207/150m): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13642 ke 16 0 218m 135m 17m S 9.6 13.4 138:33.35 firefox-bin 6766 root 15 0 344m 101m 7812 S 3.0 10.1 3066:17 X 6895 ke 16 0 37236 26m 4748 S 2.3 2.6 11:54.49 metacity 5570 lp 16 0 7204 1816 1176 S 2.0 0.2 586:08.05 cupsd 13840 ke 15 0 93172 8024 4568 S 1.7 0.8 357:39.86 evince 21035 ke 15 0 119m 102m 4580 S 0.7 10.2 135:28.25 emacs 6907 ke 15 0 108m 4292 3376 S 0.3 0.4 162:00.28 mono 6934 ke 15 0 82884 9196 4428 S 0.3 0.9 2:05.68 gnome-panel 7038 ke 16 0 9688 4472 1840 S 0.3 0.4 4:04.27 xterm 30306 ke 16 0 207m 150m 4972 S 0.3 14.9 4:23.89 wnck-applet I'd say, I only have the Window Selector in my panel (see attachment). Yes, probably they all were present. IIRC, I killed (kill -9 ...) some of them the last weeks. I never click on these applets.
Created attachment 71123 [details] gnome-panel
Please try installing http://w3.suse.de/~danw/libwnck-2.12.2-14.i586.rpm, then log out and back in, and see if that fixes the leak.
Karl?
On my workstation, I now run beta7 with libwnck-2.12.2-13. It does not seem to get started any longer by default: ps aux | grep wnck ke 9587 0.0 0.0 1900 708 pts/8 S+ 10:27 0:00 grep wnck Resource managements seems to be okay: top - 10:26:40 up 12 days, 17:23, 11 users, load average: 0.01, 0.07, 0.07 Tasks: 139 total, 1 running, 136 sleeping, 0 stopped, 2 zombie Cpu(s): 1.7% us, 2.9% sy, 23.2% ni, 68.9% id, 3.2% wa, 0.1% hi, 0.1% si Mem: 1035300k total, 1007048k used, 28252k free, 69988k buffers Swap: 1052248k total, 244640k used, 807608k free, 500588k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19653 root 15 0 175m 29m 9260 S 1 3.0 22:04.40 X 19963 ke 16 0 18628 11m 8404 S 1 1.2 1:29.81 metacity 19968 ke 15 0 514m 57m 9.9m S 0 5.7 4:26.67 gnome-panel 514/57m for gnome-panel is not optimal, but probably to be accepted.
Doh! Unfortunately, this means the bug isn't fixed; in CODE10, several applets were changed from processes to shared libraries, including the wnck-applet, so now instead of leaking into its own address space, it's leaking directly into gnome-panel. For comparison, I have: 28198 danw 15 0 36788 18m 11m S 0.0 1.8 0:55.87 gnome-panel Just to make sure, what version of libwnck do you have? The leak fixes are in 2.12.2-17, but not in 2.12.2-14 (well, unless you have the hacked up version of -14 that I pointed to in comment #13). You can grab -17 from http://hazard.provo.novell.com/unstable/nld-10-i586/libwnck.rpm. You'd need to log out and back in to test it. (Just removing the applets from the panel and re-adding them won't do the trick.)
Thanks for the detailed info. I just installed -17 and re-started the Gnome session: ke@frechet:~> rpm -q libwnck libwnck-2.12.2-17 16485 root 15 0 150m 14m 6676 S 1 1.4 0:02.00 X 17794 ke 15 0 176m 20m 15m S 1 2.0 0:02.35 gnome-panel Let's wait and see...
Can you please provide the output of pmap `pidof gnome-panel`? Which of these do you have running: - Window-list menu - Task list (buttons for all windows) - Workspace switcher - Show desktop button Also, how do you replicate the bug?
Created attachment 74867 [details] pmap-gnome-panel
See attachment. I'd say, I run all the applets you listed; I'm not sure about the task list: I've a dedicated panel on the bottom with buttons for all the open windows. I do not know, how you can replicate the bug. I use the Workspace switcher quite often. The panel is already a little bit bigger: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16485 root 15 0 173m 21m 9168 S 2 2.1 0:54.63 X 17787 ke 15 0 17016 11m 9328 S 0 1.1 0:05.23 metacity 17794 ke 15 0 195m 25m 17m S 0 2.5 0:11.50 gnome-panel 17852 ke 15 0 167m 16m 10m S 0 1.6 0:00.81 gnome-keyboard- .
Just to check - what package version do you have of gnome-panel and gnome-applets?
ke@frechet:~> rpm -q gnome-panel gnome-applets gnome-panel-2.12.2-22 gnome-applets-2.12.2-27 (IIRC, that's all from SL 10.1 beta7)
Well.... Given how reliably this bug happens for you, I assumed that someone else would eventually report a duplicate of it, and we could then figure out what the common denominator was between you. But that doesn't seem to be happening... If you want to help debug this further, you can run the panel under valgrind to figure out where the leaks are coming from. Install valgrind, gnome-panel-debuginfo and libwnck-debuginfo (you can find those at http://hazard.provo.novell.com/dist/sled-10-i586/ and presumbably other places as well). You may also need a new gnome-panel and libwnck if the ones you have aren't the most recent ones. Then, to cleanly shut down your existing gnome-panel, run "gnome-session-properties", click to the "Current Session" page, find "gnome-panel" in the list, select it, and click "Remove" and then "Apply". Then Close gnome-session-properties. Run "valgrind --num-callers=20 --leak-check=full --show-reachable=yes gnome-panel >& valgrind.out" to start a new gnome-panel. (This panel and all of the applets in it will run somewhat slowly because it's being traced by valgrind.) Once you're sure that it has definitely leaked some memory, ^C the valgrind process, and attach the valgrind.log to this bug. (And it should restart the panel for you automatically.)
ATM, it looks as follows: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25901 ke 15 0 343m 165m 19m S 10 8.2 12:44.43 memcheck I'll wait a little bit longe before attaching the log.
Created attachment 87957 [details] 1 day with valgrind I hope this helps.
Aha! You apparently have accessibility enabled, and most of the leaks seem to be coming from that code. That's why I could never reproduce it. If you didn't intend to be using the accessibility framework, go into the GNOME Control Center, open "Assistive Technology", turn off "Enable assisitive technologies", then log out and back in. That should hopefully stop the leaks. Otherwise, I'll let you know when new accessibility framework packages are available with the leaks fixed.
Thanks for your help! No, I do not use the accessibility framework, it is just enabled, probably because I was curious in the past...
There are a bunch of leak fixes in atk/gail/at-spi HEAD, but some of them don't apply cleanly to the version we're shipping in CODE10, and the ones that do apply only fix half the leakage. Given that you now have a workaround, and we don't know of anyone affected by the bug, I'm going to just close this for now and when we do import a newer version of the a11y framework in SUSE 10.2 we can make sure this bug is dead.
I need to make sure this is fixed in openSUSE 10.2.
Dan, did you have any luck fixing this in 10.2?
This is *presumed* fixed, but I never got around to actually testing it.
There's still some possible minor atk/gail/at-spi-related leakage in 10.3 (10.2 being somewhat moot, as what leakage I've noticed there is similarly minor), and there's also libwnck-related leakage, but there's no apparent overlap. I'm also not sure just from looking at the valgrind log how much (if any) of the leakage is actually attributable to either set of libraries. I'm inclined to close this bug (since the leakage which was originally reported seems fixed) and open another for the current leakage. Log to follow.
Created attachment 181818 [details] admittedly only about half an hour with valgrind I made a point of exercising the window manager rather heavily so as to hit libwnck as hard as I could.
This leak fixed, on to the next...