User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: On every press of F5 there is a memeleak noticable by looking at top -p <pidofxfdesktop> It is larger the more regular file icons theer are on the desktop. A minimum leak is about 124-128K per refresh, with many icons it can be hundreds of Kb. It is also affected apparently by the state of the icon cache size even if those icons are deleted and no longer on the screen, but did not find a clear correlation. Reproducible: Always Steps to Reproduce: Keep refreshing the desktop after doing a touch ~/Desktop/{1..50}
Yeah, not surprised. I changed memory handling a bit last night; didn't quite finish fixing leaks. What icon cache?
Created attachment 826 valgrind log Not terribly conclusive. Most of the hal/dbus stuff is a memleak in HAL that I filed a bug on, after which I was told it wasn't a bug (bullshit). The other stuff is mostly un-freeable memory. Some of the icon related stuff seems like it might have something to do with us, but I'm not seeing where. I've verified that whenever you hit F5, each icon is actually destroyed (i.e., the XfdesktopIcon instance for it gets finalised). So I'm not really sure at this point.
This leak has been there for at least a few weeks it is not the result of the recent commits. Icon cache -> the per-screen rc file with the desktop icon positions. The larger the file, the larger the leak apparently. I ran valgrind a few days ago with --show-reachable as that's where the hundreds of K lost are as shown in the summary of your log as well. The other losses only amount to at most a few K. The lossy alloc seemed to be inside xfce_parse_rc IIRC in allocating memory for a new section (group), so I thought it even may be a libxfce4util leak which was not exposed so far since there are no other heavy users of such large rc files ,as this cache can grow if the user has many icons. But I did not look more carefully into it.
*** Bug 2595 has been marked as a duplicate of this bug. ***
This leak doesn’t seem to necessarily have to do with the icons since I am experiencing something similar without any icons on desktop.
(In reply to comment #5) > This leak doesn’t seem to necessarily have to do with the icons since I am > experiencing something similar without any icons on desktop. Then it might be related to bug #1914?
> > This leak doesn’t seem to necessarily have to do with the icons since I am > > experiencing something similar without any icons on desktop. > > Then it might be related to bug #1914? Since I don’t use xfce4-menu-plugin either, I don’t think so.
(In reply to comment #7) > > > This leak doesn’t seem to necessarily have to do with the icons since I am > > > experiencing something similar without any icons on desktop. > > > > Then it might be related to bug #1914? > > Since I don’t use xfce4-menu-plugin either, I don’t think so. Nothing to do with the plugin. If you have the right-click desktop menu active, it's the same code.
> > > > This leak doesn’t seem to necessarily have to do with the icons since I am > > > > experiencing something similar without any icons on desktop. > > > > > > Then it might be related to bug #1914? > > > > Since I don’t use xfce4-menu-plugin either, I don’t think so. > > Nothing to do with the plugin. If you have the right-click desktop menu active, it's the same code. Alright, then this might be the case. Anything I can do?
Just to let you know: The latest version (4.3.99.2) does not take as much memory as before. It does still eat a bit of memory after some time but a lot slower. (Before: ~300MB in 2 days, Now: ~100MB in 3 days.)
Created attachment 946 valgrind log, xfdesktop_file_icon_manager_add_icon()
I'm able to reproduce this with the same procedure: pressing f5 on the desktop. I've run valgrind on xfdesktop and found these few major leaks, which all seem to come from xfdesktop_file_icon_manager_add_icon(). These are listed in the attachment above. No other leaks really come close to these leaks, except one or two which don't really seem to originate from xfdesktop. In any case, I don't usually use file/launcher icons, and firefox puts all stuff I download in ~/Desktop. Thus I've got 190 files in ~/Desktop, which may explain why this leak would be so significant here. top reports that every time I press f5, the memory usage of xfdesktop increases by 3-4mb.
might also be some huge leak in the resource config file parser...
I've taken a closer look at this, and I find it likely that at least the leak in xfdesktop_file_icon_manager_add_icon() is caused by the resurce config file parser. xfdesktop_file_icon_manager_add_icon() seems to use the rc parser correctly. Also, all the memory that leaks is reported to be allocated at xfce-rc-simple.c:137 in simple_add_group(). That this line is called through xfdesktop-file-icon-manager.c:2074 might just be a coincidence. If it's the rc parser that's buggy, this bug should be reassigned to Benny, right?
Did you set the env vars G_DEBUG=gc-friendly and G_SLICE=always-malloc before running valgrind? Those "leaks" look like gslice just normally caching memory.
(BTW, if you're going to post a valgrind log, please post the *entire* log.)
I did mean to link to the full valgrind log on my server, but apparently I forgot it. The full log is on ftp://eulex.zapto.org/xfdesktop3.log . I did set G_SLICE=always-malloc, but not G_DEBUG=gc-friendly, as I didn't know about the latter. Anyway, something to test tomorrow :)
On a related note, I did see calls to the slab allocator when I didn't run it with G_SLICE=always-malloc, and after I added that (after Ori pointed me to it) I don't see them anymore. Also, another thing that might matter: I shut down xfdesktop by running xfdesktop --quit, to make the app itself clean up as much as possible before quitting, to just try to catch real leaks in the log.
(In reply to comment #17) > I did mean to link to the full valgrind log on my server, but apparently I > forgot it. The full log is on ftp://eulex.zapto.org/xfdesktop3.log . Hmm, that gives me "550 failed to change directory". > I did set > G_SLICE=always-malloc, but not G_DEBUG=gc-friendly, as I didn't know about the > latter. Anyway, something to test tomorrow :) Ok, well, that's encouraging. Assuming your log is correct, unfortunately it doesn't tell me much about where to look for the problem. I mean... I don't need a valgrind log to know that a memleak from hitting F5 means that the icons aren't getting freed properly. That's obvious. The problem is, I've added debugging printfs that show that all the XfdesktopIcons are indeed dropping their refcnt to 0 on refresh, so I don't know what the problem could be. (In reply to comment #18) > Also, another thing that might matter: I shut down xfdesktop by running > xfdesktop --quit, to make the app itself clean up as much as possible before > quitting, to just try to catch real leaks in the log. That's good; that should indeed have the effect you expect.
Gah, nevermind. Of course, as you said, the 'leaks' appear to be in the XfceRc usage, not the icon itself. I'd be really surprised if there was a memleak in XfceRc, though. But maybe Benny has some ideas -- Benny, see Alex's valgrind log attachment: he had G_SLICE=always-malloc, but NOT G_DEBUG=gc-friendly, so maybe it's not useful...
I'm sorry. I meant ftp://eulex.zapto.org/xfdesktop2.log .
I'll rerun it with G_DEBUG=gc-friendly when I come home again later today.
XfceRcSimple uses memory/string chunks, which are freed in _xfce_rc_simple_close(). It's indeed a memory leak! Check gmem.c from glib. The memory allocated via memory chunks is not freed on g_mem_chunk_destroy(). Amazing breakage in GLib!
So does that mean xfdesktop will always leak if I continue to use XfceRc? Or is this a bug localised to a certain version of glib?
Nevermind, I looked at it myself. Seems this bug was introduced into glib after GMemChunk started using the slice allocator. GMemChunks don't keep track of the list of allocated pieces of memory anymore, so they can't be freed on destroy. This bug looks sorta related, but not really: http://bugzilla.gnome.org/show_bug.cgi?id=352889
It's a GNOME complot, for sure! :-) With this GLib "feature" basically all Xfce applications leak memory... I'll try to change XfceRc to not use memory chunks, as I doubt that the GNOME will fix this leaker any time soon.
Created attachment 952 glib memleak workaround patch Ok, did a little more digging. GStringChunk (at least in glib 2.10) seems to be ok; it doesn't use the slice allocator at all (just uses g_new(), and g_free()s the data on g_string_chunk_free(). GMemChunk is of course b0rked. Here's a patch for XfceRcSimple that works around the glib memleak, and should be safe even in the unlikely event that the glib bug gets fixed. I haven't re-checked the memleak, but xfdesktop doesn't crash at least. What do you think, Benny?
I've committed a patch yesterday to libxfce4util (dropping GMemChunk completely just to be sure). Please verify this, so we can close the bug report.
At least it does seem to leak a lot less than before. This particular leak is probably fixed, now there are just smaller leaks left. However, with this patch I can make xfdesktop crash if I keep on pressing f5 on the desktop for a while (10 times, maybe): ** (xfdesktop:28805): CRITICAL **: xfdesktop_file_icon_peek_info: assertion `XFDESKTOP_IS_FILE_ICON(icon)' failed (xfdesktop:28805): GLib-GObject-WARNING **: invalid uninstantiatable type `XfdesktopRegularFileIcon' in cast to `GObject' (xfdesktop:28805): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (xfdesktop:28805): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1488329024 (LWP 28805)] xfdesktop_regular_file_icon_new (info=0xa5c04a40, screen=0x80950f0) at xfdesktop-regular-file-icon.c:636 636 regular_file_icon->priv->info = thunar_vfs_info_ref(info); (gdb) bt #0 xfdesktop_regular_file_icon_new (info=0xa5c04a40, screen=0x80950f0) at xfdesktop-regular-file-icon.c:636 #1 0x0806a8f8 in xfdesktop_file_icon_manager_add_regular_icon ( fmanager=0x8099de8, info=0x0, defer_if_missing=1) at xfdesktop-file-icon-manager.c:2161 #2 0x0806a9ee in xfdesktop_file_icon_manager_listdir_infos_ready_cb ( job=0x81d2b48, infos=0x8290d10, user_data=0x8099de8) at xfdesktop-file-icon-manager.c:2477 #3 0xa7e5ec42 in _thunar_vfs_marshal_BOOLEAN__POINTER (closure=0x82689e8, return_value=0xafad8f50, n_param_values=2, param_values=0xafad902c, invocation_hint=0xafad8f3c, marshal_data=0x806a9a0) at thunar-vfs-marshal.c:82 #4 0xa781098b in IA__g_closure_invoke (closure=0x82689e8, return_value=0xafad8f50, n_param_values=2, param_values=0xafad902c, invocation_hint=0xafad8f3c) at gclosure.c:490 #5 0xa7820f2d in signal_emit_unlocked_R (node=0x80dc968, detail=0, instance=0x81d2b48, emission_return=0xafad91ec, instance_and_params=0xafad902c) at gsignal.c:2440 #6 0xa7822208 in IA__g_signal_emit_valist (instance=0x81d2b48, signal_id=113, detail=0, var_args=0xa4ce4340 "PCΤ") at gsignal.c:2209 #7 0xa7e68c75 in thunar_vfs_job_source_dispatch (source=0x82a4388, callback=0, user_data=0x0) at thunar-vfs-job.c:471 #8 0xa774c731 in IA__g_main_context_dispatch (context=0x8099738) at gmain.c:2045 #9 0xa774f7a6 in g_main_context_iterate (context=0x8099738, block=1, dispatch=1, self=0x807e048) at gmain.c:2677 #10 0xa774fb67 in IA__g_main_loop_run (loop=0x8213090) at gmain.c:2881 #11 0xa7c2f281 in IA__gtk_main () at gtkmain.c:1003 #12 0x0805591c in main (argc=Cannot access memory at address 0x0 ) at main.c:394 (gdb) Before this crash, I managed to increase the memory usage of xfdesktop from 14mb to 15 or 16mb. Still much better than before.
I suspect it's a memory management problem, as every time I rerun it in gdb, it crashes in a different location.
(In reply to comment #29) > At least it does seem to leak a lot less than before. Is this just related to refresh with F5, or does it just leak from other sources? > This particular leak is > probably fixed, now there are just smaller leaks left. Can you verify with valgrind? For some reason I've been unable to see the xfce_rc leak myself. > However, with this patch > I can make xfdesktop crash if I keep on pressing f5 on the desktop for a while > (10 times, maybe): This is unrelated; please file a separate bug.
(In reply to comment #31) > (In reply to comment #29) > > At least it does seem to leak a lot less than before. > > Is this just related to refresh with F5, or does it just leak from other > sources? > > > This particular leak is > > probably fixed, now there are just smaller leaks left. > > Can you verify with valgrind? For some reason I've been unable to see the > xfce_rc leak myself. I've verified with valgrind, and now there seem to be no memory leaks related to f5, and actually there seems to be no leaks in xfdesktop itself; only some smaller leaks in the libraries that xfdesktop uses. Valgrind log attached. > > However, with this patch > > I can make xfdesktop crash if I keep on pressing f5 on the desktop for a while > > (10 times, maybe): > > This is unrelated; please file a separate bug. > Ok, done (#2806)
Created attachment 959 valgrind log with no leak :)
Comment on attachment 959 valgrind log with no leak :) Meh. Anyone know how to make Firefox display text/x-log mime types inline? It keeps asking me to save these :-P
The entries that look like this kinda bother me: ==29203== 36,048 (936 direct, 35,112 indirect) bytes in 78 blocks are definitely lost in loss record 5,260 of 6,764 ==29203== at 0x401D38B: malloc (vg_replace_malloc.c:149) ==29203== by 0x47A8CC5: g_malloc (gmem.c:131) ==29203== by 0x47B871F: g_slice_alloc (gslice.c:777) ==29203== by 0x479F4E5: g_list_prepend (glist.c:95) ==29203== by 0x41D1A7A: gtk_container_children_callback (gtkcontainer.c:2056) ==29203== by 0x4273020: gtk_menu_shell_forall (gtkmenushell.c:885) ==29203== by 0x41D2CE8: gtk_container_foreach (gtkcontainer.c:1292) ==29203== by 0x41D2D64: gtk_container_get_children (gtkcontainer.c:1377) ==29203== by 0x7FB531A: ??? ==29203== by 0x7FB6230: ??? ==29203== by 0x7FB66CF: ??? ==29203== by 0x7FB67B0: ??? I don't think they should be there. Can you run valgrind again with '--num-callers=50'? Valgrind's default stack trace size is uselessly low. Oh, and could you also try something else...? To make sure it's just desktop related, could you disable the right-click menu in the Desktop Settings panel before running xfdesktop? I'm pretty sure there are still some memleaks lurking in the menu code (which I can't reliably find, unfortunately), and I want to make sure we're just dealing with problems with the icon view.
Created attachment 961 valgrind log now run with --num-callers=50
*** Bug 2986 has been marked as a duplicate of this bug. ***
Pretty sure we fixed this with the libxfce4util changes in 4.4.1.
Let's reopen this guy. Looks like we have more issues with reloading, and I'd rather keep this open than have a new one opened.
*** Bug 3314 has been marked as a duplicate of this bug. ***
Ok, just to be clear, I need valgrind logs. valgrind should be run like so: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind -v --leak-check=full \ --leak-resolution=high --num-callers=50 --log-file=xfdesktop-valgrind \ xfdesktop Be absolutely sure that you are running Xfce 4.4.1 and nothing below. There are some leaks that were fixed between .0 and .1. Post your logs here. DO NOT gzip them. Make sure the content type is set to text/plain. I want to be able to read them in my browser.
Created attachment 1350 valgrind output for xfce-4.4.1 valgrind output for xfce-4.4.1, xfdesktop -reload was issued several times xfce-4.4.1, xfdesktop -reload was issued several times. valgrind command: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high --num-callers=50 --log-file=xfdesktop-valgrind xfdesktop
Created attachment 1353 valgrind output from xfdesktop 4.4.1 command line: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind -v --leak-check=full --leak-resolution=high --num-callers=50 ./xfdesktop >& valgrind.out Now I watched the memory usage grow: $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 147984 kB VmRSS: 85612 kB $ xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 157952 kB VmRSS: 96656 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 163460 kB VmRSS: 103404 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 169992 kB VmRSS: 109268 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 175484 kB VmRSS: 115168 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 181072 kB VmRSS: 121184 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 189636 kB VmRSS: 129288 kB $ ./xfdesktop --reload $ grep -E "VmSize|RSS" /proc/`pidof valgrind.bin`/status VmSize: 196168 kB VmRSS: 135252 kB
*** Bug 3448 has been marked as a duplicate of this bug. ***
Mathias: regarding attachment #1354 on bug #3448, did you run with G_SLICE=always-malloc and G_DEBUG=gc-friendly? There are some weird 'possibly lost' records in there that look suspicious...
(In reply to comment #45) > Mathias: regarding attachment #1354 on bug #3448, did you run with > G_SLICE=always-malloc and G_DEBUG=gc-friendly? No; I wrote down which options I used based on what you recommended on the general Xfce discussion list a while ago. I never heard of those two variables (?) > There are some weird 'possibly > lost' records in there that look suspicious... Then I’ll make another run including those variables above.
(In reply to comment #46) > (In reply to comment #45) > > > There are some weird 'possibly > > lost' records in there that look suspicious... > > Then I’ll make another run including those variables above. Great, thanks. Sorry if I left that out the last time.
Created attachment 1357 Xfdesktop running through valgrind (In reply to comment #46) > Then I’ll make another run including those variables above. Which is done hereby.
(In reply to comment #48) > Created an attachment (id=1357) [details] > Xfdesktop running through valgrind > > (In reply to comment #46) > > Then I’ll make another run including those variables above. > > Which is done hereby. Unfortunately not useful. Valgrind only does the memory leak analysis when the program quits cleanly. ctrl+c or 'xfdesktop --quit' will work here.
(In reply to comment #49) > (In reply to comment #48) > > Created an attachment (id=1357) [details] [details] > > Xfdesktop running through valgrind > > > > (In reply to comment #46) > > > Then I’ll make another run including those variables above. > > > > Which is done hereby. > > Unfortunately not useful. Valgrind only does the memory leak analysis when the > program quits cleanly. ctrl+c or 'xfdesktop --quit' will work here. It doesn’t work this way here. I have to forcefully kill both applications.
Created attachment 1528 valgrind log with 10 reload Ok, I run valgrind as specified in this BR. xfdesktop 4.4.2 (not patched for menu code leak but it shouldn't be relevant) glib 2.14.6 gtk 2.12.8 I only ran xfdesktop trough valgrind. it loads two desktop backgrounds (dual screen with randr 1.2) then idles. Then I run 10 times xfdesktop -reload with 10 seconds pause between. Then more idle, then quit.
(In reply to comment #51) > Created an attachment (id=1528) [details] > valgrind log with 10 reload This was taken using a stripped build of xfdesktop and the xfce libs. Not very useful to pinpoint things. Those callstacks with g_node_traverse() in them look interesting. And apparently a GHashTable is leaking? Odd, I've never seen that before. Also make sure you're using latest xfce_4_4 branch svn -- there's a memleak plugged in there since 4.4.2.
Created attachment 1529 valgrind with 10 reloads Another valgrind log, with the two patches recently commited to XFCE_4_4 branch Missing symbols too, but I don't have all xfce libs symbol currently (we really need to build -dbg packages for these).
(In reply to comment #53) > Created an attachment (id=1529) [details] > valgrind with 10 reloads Are you sure you have the patch from a few days ago that adds the g_list_free() after the gtk_container_get_children()? I'm still seeing that one show up in the log, and I don't see how that could still be there. But, the GPtrArray leak is gone, which is good news. I see a potential GNode leak (probably real, but this one will be *really* hard to find/fix), and a GHashTable leak (which might be valgrind being stupid; I intentionally 'leak' one GHashTable, though should still look into this). There's also an apparent XfceAppMenuItem leak, which doesn't make sense, unless gtk_widget_destroy() on an unanchored widget doesn't actually destroy it. That would be lame.
(In reply to comment #54) > (In reply to comment #53) > > Created an attachment (id=1529) [details] [details] > > valgrind with 10 reloads > > Are you sure you have the patch from a few days ago that adds the g_list_free() > after the gtk_container_get_children()? I'm still seeing that one show up in > the log, and I don't see how that could still be there. What I have is the two following patches: http://svn.xfce.org/index.cgi/xfce/revision/?rev=26635 http://svn.xfce.org/index.cgi/xfce/revision/?rev=26652 Did I miss something?
(In reply to comment #55) > What I have is the two following patches: > http://svn.xfce.org/index.cgi/xfce/revision/?rev=26635 > http://svn.xfce.org/index.cgi/xfce/revision/?rev=26652 > > Did I miss something? No, that should be correct. Well, if you can do a run with debugging symbols, might be able to figure out why they're showing up in the trace.
Created attachment 1533 with debug symbols (except thunar related stuff)
xfdesktop git shows no big leaks on F5 and this isn't hasn't been reported for 4.10. Closing bug report.