User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008011910 Minefield/3.0b3pre Build Identifier: Greetings. I have had at least two folks report that they are seeing very bad memory leaks from xfdesktop and xfce4-menu-plugin using 4.4.2 in Fedora 8. See: https://bugzilla.redhat.com/show_bug.cgi?id=428662 for more info on what they are seeing. I also see a Ubuntu bug that looks very similar: https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/77702 Note that at least the Fedora reporters do not have 'start kde/gnome' on login, or are switching backgrounds regularly. Also note that I (and many other Xfce users) do not see this behavior here. Reproducible: Always Steps to Reproduce: 1. login to an Xfce desktop 2. Wait Actual Results: xfdesktop and xfce4-menu-plugin grow to take more and more memory. Expected Results: Memory usage should stay pretty constant
Oh, if I can ask for any additional info from the Fedora reporters, just let me know, or feel free to ask them on the fedora bug directly.
I need valgrind logs. See bug #2427 for more info on exactly what I need. I don't really have the time or inclination to do all the info-gathering on my own.
There is some valgrind output here: https://bugzilla.redhat.com/attachment.cgi?id=292560 I am trying to get them to repeat with debuginfo installed and with the command line you want.
Created attachment 1497 valgrind output Same as https://bugzilla.redhat.com/attachment.cgi?id=292574 from the Fedora bug.
Hey Brian. Any chance to look over the logs from comments #3 and #4? If you let me know whats lacking I can try and gather info from reporters for you.
Haven't really had time lately, sorry.
No worries. Let me know if I can gather any more info.
Ok, got one. Not freeing the return from gtk_container_get_children() in _menu_shell_insert_sorted(). Fixed on 4.4 branch in rev 26635. There are probably more, though...
Excellent. Would it be worthwhile for me to spin up fedora rpms with that fix so we can have the folks that can reproduce it test and provide further info? Or should we wait and let you poke at it some more and see if you can squash some more leaks first?
Kevin, sure, might want to just go ahead. My time to work on this is pretty sporadic, so it might be a while before any more of these get fixed without help from others.
I've spun up a scratch build in the fedora build system with this patch and asked the fedora reporters to see if they can test and report back. Will let you know what we find. Thanks for looking!
(In reply to comment #11) > I've spun up a scratch build in the fedora build system with this patch and > asked the fedora reporters to see if they can test and report back. > > Will let you know what we find. Thanks for looking! > I've integrated the patches (r26652 and r26635) in debian packages 4.4.2-5, but it *seems* some people still have memory leaks in xfce4-menu-plugin. You can see one bug report here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478505 I've asked the bug reporter to provide a valgrind log here, so lets hope something will appear. Thank for the work.
As xfce4-menu-plugin is started automatically, and not by me from a shell, I don't know how to run it under valgrind. Please provide instructions. Thanks. I haven't found a way to attach valgrind to an existing process (which I kinda understand why it is not possible), so I'm stuck. Can I just kill xfce4-menu-plugin and restart it under valgrind with the same arguments it was started under? Or is there some configuration option somewhere in xfce4 which I missed which allows me to override the command used to launch xfce4-menu-plugin?
There are some info on how to do this on bug #2427
I have read through the whole bug log of #2427 (before posting my previous comment), but I still don't know what am I supposed to do. 1) Am I supposed to kill xfce4-menu-plugin and rerun it from a shell under valgrind (without restarting my whole X session)? 2) Am I supposed to change some configuration variable of xfce4 (which one?) whose default value is "xfce4-menu-plugin" to "G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high --num-callers=50 --log-file=/tmp/xfdesktop-valgrind xfce4-menu-plugin" and then restart my whole X session? 3) Am I supposed to move /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin to /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin.orig and create a shell script named /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin that will run /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin.orig under valgrind and then restart my whole X session? 4) Something else?
(In reply to comment #15) > I have read through the whole bug log of #2427 (before posting my previous > comment), but I still don't know what am I supposed to do. > > 1) Am I supposed to kill xfce4-menu-plugin and rerun it from a shell under > valgrind (without restarting my whole X session)? Yes. You can save yourself the need to restart the whole X session, restarting xfce4-panel should be enough. > 2) Am I supposed to change some configuration variable of xfce4 (which one?) > whose default value is "xfce4-menu-plugin" to "G_DEBUG=gc-friendly > G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high > --num-callers=50 --log-file=/tmp/xfdesktop-valgrind xfce4-menu-plugin" and then > restart my whole X session? No, this is the command line to run xfce4-menu-plugin through valgrind > 3) Am I supposed to move /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin to > /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin.orig and create a shell script > named /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin that will run > /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin.orig under valgrind and then > restart my whole X session? Yes. Put in the shell script the command in 3)
(In reply to comment #16) >> 2) Am I supposed to change some configuration variable of xfce4 (which one?) >> whose default value is "xfce4-menu-plugin" to "G_DEBUG=gc-friendly >> G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high >> --num-callers=50 --log-file=/tmp/xfdesktop-valgrind xfce4-menu-plugin" and then >> restart my whole X session? > No, this is the command line to run xfce4-menu-plugin through valgrind Well, as the leak is in xfce4-menu-plugin, that seemed like a good candidate to be run through valgrind.
Created attachment 1613 Valgrind output - probably faulty
Anyway, I replaced /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin by a wrapper that runs it through valgrind, but no xfce menu appears, and I these messages: ==26636== Too many suppression files specified. ==26636== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26645== Too many suppression files specified. ==26645== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26646== Too many suppression files specified. ==26646== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26647== Too many suppression files specified. ==26647== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26648== Too many suppression files specified. ==26648== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26649== Too many suppression files specified. ==26649== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. ==26650== Too many suppression files specified. ==26650== Increase VG_CLO_MAX_SFILES and recompile. valgrind: Bad option '--suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp'; aborting. valgrind: Use --help for more information. The wrapper is: #! /bin/sh G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high --num-callers=50 --log-file=/tmp/xfdesktop-valgrind /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin "$@" That's probably a Debian-specific problem, so maybe you'll have a clue for me, Yves-Alexis?
Ah, this seems to be a bug in the Debian valgrind wrapper, adding the --suppressions command multiple times when valgrind reexecutes itself. I fixed that, but now it seems to me that valgrind is stuck in an infinite loop of reexecuting itself: master@piperine:~$ strace -p28547 2>&1|grep ^exec execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0 execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0 execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0 execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0 execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0 execve("/usr/bin/valgrind", ["valgrind", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 42 vars */]) = 0 execve("/usr/lib/valgrind/amd64-linux/memcheck", ["/usr/bin/valgrind.bin", "-v", "--leak-check=full", "--leak-resolution=high", "--num-callers=50", "--log-file=/tmp/xfdesktop-valgri"..., "/usr/lib/xfce4/panel-plugins/xfc"..., "socket_id=16777267", "name=xfce4-menu", "id=12098086641", "display_name=Xfce Menu", "size=36", "screen_position=11"], [/* 43 vars */]) = 0
Ah, that was my (stupid) error, the wrapper reexecutes itself instead of the .orig file. Sorry for the noise.
Created attachment 1614 Valgrind output
(In reply to comment #22) > Created an attachment (id=1614) [details] > Valgrind output > Unfortunately this doesn't show any leaks... just the usual false-positive leaks from gtk, gobject, and fontconfig.
Created attachment 1643 Valgrind output Another valgrind output, from Santiago Ruano Rincón on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376177
(In reply to comment #24) > Created an attachment (id=1643) [details] > Valgrind output > > Another valgrind output, from Santiago Ruano Rincón on > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376177 Loss record 97 looks interesting, but can't do much with it since there're no debug symbols.
Created attachment 1645 Valgrind output Another valgrind output. xfdesktop run during 12+ hours, with a script which reloaded it and try to trigger the menu (which failed once the screensaver run, I'll try another run tonight without screensaver). Not sure any useful leak appears there...
Created attachment 1646 Script to reload and refresh menu This script reload xfdesktop, popups the menu and refresh it endlessly.
Created attachment 1648 Yet another valgrind log Ok, this one run during a day, and with the reload, refresh menu and popup menu. Desktop icons were activated.
(In reply to comment #28) > Created an attachment (id=1648) [details] > Yet another valgrind log Similar to my last comment... loss record 1950 looks like it's probably my fault, but the crucial bits of the stack trace are missing. Not sure why :-( . I don't understand loss record 3979. The GLists returned by thunarx are definitely all freed (see xfdesktop_file_icon_manager_real_init() and _fini()). Ah, I see. That's actually inside thunarx_provider_factory_load_modules() -- thunarx does a bit of caching; I doubt that's a real leak (and if it is, it's a thunar bug). Loss record 5195 is a one-time allocation that never gets freed by design. 5349 and 5378 are like 1950 -- need more info. Not sure about 5566, but seems similar to 5195. 5876, 5887, 5941, 5967, 6013, 6051 are probably my fault, suffer from the same problem as 1950, and are additionally probably very difficult to find, even with the full stack trace. 5944, 5957, 5971, 5976, 5979, 5980, 5982, 5983, 6048 are very puzzling. There was only one instance in the menu module where gtk_container_get_children() was missing a corresponding g_list_free(), which was fixed in svn rev 26635. I'm not sure what to make of this, and the blank parts in the stack trace are a big problem. There's a lot of mem supposedly lost here, so it's likely this is a problem. 5958 is another 1950 -- missing crucial stacktrace info. 5977, 5999, 6018 looks like lots of menu items aren't getting destroyed -- or it could just be that the cached menu widget isn't getting destroyed when the app quits. I'd assume the latter, cuz I can't see how we'd be losing track of menu items like that. But this is probably worth looking into. 6004, 6021 are more 1950s. Any I didn't mention are just non-leaks in libc/freetype/pango/gtk/etc. I'm really confused by the broken stack traces. The "??"s in many of those cases should be inside xfdesktop or in the menu module. Is it possible the menu module's debuginfo isn't working properly? Or... something else? Also it might be helpful to try an unoptimised build -- I see a few areas there where some functions on the stack are missing (probably inlined), and it's a little annoying to read that way.
Created attachment 1795 Valgrind output for menu plugin I ran the menu plugin under valgrind for about 1.5 months; the menu plugin's memory consumption grew to 10.7GB, then I killed it and here is the corresponding valgrind log (which took about a day to be generated after the killing :-) ). In the same time, xfdesktop grew to 2433MB, but I was not running it under valgrind, so no info.
Wow, that's great! I don't have time to look at this right now (and likely this bug is moot with 4.6), but it would be nice to have a relatively leak-free 4.4 if we do a final 4.4.3 release in that series.
Created attachment 2043 valgrind leak log I have similar problems with 4.6 still. I let xfdesktop run over night in valgrind, and memory consumption grew from 7% to 20%. There were several messages on the console: DBG[desktop-menu.c:353] _generate_menu(): menu file name is /etc/xdg/menus/xfce-applications.menu Possibly caused by application updates, which are automatically done at night.
Created attachment 2044 valgrind leak log, uncompressed!
It might be noteworthy that I hardly used the computer during the time this log was created. I opened up the right-click menu a couple of times to admire the time it took to come up in valgrind, but then I left for the day. And this morning when I came back in, the memory usage had already grown to what I described above.
Looks like this is still a problem with xfce-4.5.99.1 https://qa.mandriva.com/show_bug.cgi?id=47835
Changing components on this bug. I can confirm it for rc1 as well on both i386 and amd64. The bug is probably triggered by regenerating the menu. On my machine for some reason, the menu is regenerated approx. every 4 mins (just by monitoring with strace). If we can't fix this before the release, we need to mention this in the release notes in my opinion.
Created attachment 2182 Patch to fix the memory leak The attached patch cleans up a bit xfce-menu-item-cache (and fixes a typo in xfce-menu). The real source of the leak was that at the end of xfce_menu_item_cache_lookup, when all lookup methods failed and a new menu item is created, its reference count was increased. Yes, it is stored in a hash table at the same time, but that is accounted for by the initial reference count of 1 it starts out with. All code paths I saw which use xfce_menu_item_cache_lookup always increase the reference count when they store the menu item again, thus leading to a leak of all the menu items whenever the cache was cleared. Also I noticed that the tdb caching code was unfinished, and since we are about to release, I took the liberty to comment it out again. That's separate from the leak but since I just spend so much time with the code, I thought it wouldn't hurt. I'll fix the patch should that for some reason not be desirable.
Thanks, David. I've applied your patch in revision r29520: * libxfce4menu/xfce-menu-item-cache.c: Deactivate all the TDB related code because it's not used anyway. Don't increase the reference count on new menu items in xfce_menu_item_cache_lookup() as this causes increasing memory leaks. Patch by David Mohr (bug #3812). * libxfce4menu/xfce-menu.c: Fix typo in the installation of the "deleted" property of XfceMenu. Patch by David Mohr.
Close bug reports of archived products.