http://bugs.gentoo.org/351546 xfce-extra/xfce4-xkb-plugin-0.5.3.3-r9 tends to 'accumulate' the memory usage. It uses about 20Mb of resident memory just after start, but after some hours of work it grows up to 300Mb, for example. Maybe, it does not erase the information about keyboard layouts in already closed windows? + + + + + + Almost the same description here (Xubuntu Maverick Meerkat 64bit): Plugin starts using 11 MiB and then keeps growing up after new window opened (program, caption, dialog etc.). Sometimes it grows over 300 MiB. $ LANG=C apt-cache policy xfce4-xkb-plugin xfce4-xkb-plugin: Installed: 0.5.3.3-3ubuntu4 Candidate: 0.5.3.3-3ubuntu4 Version table: *** 0.5.3.3-3ubuntu4 0 500 http://ppa.launchpad.net/koshi/xfce-4.8/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status 0.5.3.3-3ubuntu2 0 500 http://archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
Yes, I know about this bug well. I'm trying to hunt memory leaks before release 0.5.4.0.
There is one leak in xkb_settings_update_from_ui(): g_strdup() is called over g_strconcat() that already allocates a new string. Moreover, kbd_config->layouts and kbd_config->variants seem to be overwritten several times inside the while loop.
(In reply to comment #2) > There is one leak in xkb_settings_update_from_ui(): g_strdup() is called over > g_strconcat() that already allocates a new string. True, fixed. I suspect that app leaks memory in operations with GHashTable in xkb-config.c, it seems it not frees memory on g_hash_table_remove().
Created attachment 3621 Fix-memory-leaks.patch This patch should fix some memory leaks. But I'm sure not all memory leaks in that code.
Created attachment 3623 Fix-more-memory-leaks.patch Fix more memory leaks. In additional I suspect that there is many objects which are not unreferenced when this is needed.
Patch pushed to git master plus a few other leaks plugged, I'll track other leaks using valgrind.
Thanks, I'll try the current git snapshot. Even with my patches memory leaks were still really huge. Just as a suggestion, if my suspicions about non-unreferenced objects are justified, refdbg (http://refdbg.sourceforge.net) may be more suitable tool for tracking leaks then valgrind.
Is there a target date for 0.5.4? (I wondering if I should work on rebasing these fixes against 0.5.3 to be used in Fedora 15?)
(In reply to comment #8) > Is there a target date for 0.5.4? (I wondering if I should work on rebasing > these fixes against 0.5.3 to be used in Fedora 15?) Ehh, 0.5.4 already released, but without these fixes. I'll release 0.5.4.1 on this weekend.
*** Bug 8357 has been marked as a duplicate of this bug. ***