! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
large memleaks on F5 or 'xfdesktop --reload'
Status:
RESOLVED: FIXED
Severity:
critical
Product:
Xfdesktop
Component:
General

Comments

Description Jani Monoses 2006-10-13 09:09:17 CEST
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}
Comment 1 Brian J. Tarricone (not reading bugmail) 2006-10-13 20:09:10 CEST
Yeah, not surprised.  I changed memory handling a bit last night; didn't quite finish fixing leaks.

What icon cache?
Comment 2 Brian J. Tarricone (not reading bugmail) 2006-10-14 01:43:15 CEST
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.
Comment 3 Jani Monoses 2006-10-15 09:19:22 CEST
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.
Comment 4 Brian J. Tarricone (not reading bugmail) 2006-11-20 17:10:24 CET
*** Bug 2595 has been marked as a duplicate of this bug. ***
Comment 5 Mathias Brodala 2006-11-20 17:37:14 CET
This leak doesn’t seem to necessarily have to do with the icons since I am experiencing something similar without any icons on desktop.
Comment 6 Brian J. Tarricone (not reading bugmail) 2006-11-20 22:54:31 CET
(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?
Comment 7 Mathias Brodala 2006-11-20 23:05:04 CET
> > 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.
Comment 8 Brian J. Tarricone (not reading bugmail) 2006-11-20 23:07:19 CET
(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.
Comment 9 Mathias Brodala 2006-11-20 23:13:16 CET
> > > > 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?
Comment 10 Mathias Brodala 2006-12-26 10:09:52 CET
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.)
Comment 11 Alexander Toresson 2007-01-21 20:24:11 CET
Created attachment 946 
valgrind log, xfdesktop_file_icon_manager_add_icon()
Comment 12 Alexander Toresson 2007-01-21 20:28:13 CET
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.
Comment 13 Alexander Toresson 2007-01-21 20:38:55 CET
might also be some huge leak in the resource config file parser...
Comment 14 Alexander Toresson 2007-01-21 21:35:47 CET
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?
Comment 15 Brian J. Tarricone (not reading bugmail) 2007-01-21 21:37:34 CET
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.
Comment 16 Brian J. Tarricone (not reading bugmail) 2007-01-21 21:38:36 CET
(BTW, if you're going to post a valgrind log, please post the *entire* log.)
Comment 17 Alexander Toresson 2007-01-21 22:22:11 CET
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 :)
Comment 18 Alexander Toresson 2007-01-21 22:28:23 CET
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.
Comment 19 Brian J. Tarricone (not reading bugmail) 2007-01-21 23:32:56 CET
(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.
Comment 20 Brian J. Tarricone (not reading bugmail) 2007-01-21 23:40:04 CET
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...
Comment 21 Alexander Toresson 2007-01-22 06:48:52 CET
I'm sorry. I meant ftp://eulex.zapto.org/xfdesktop2.log .
Comment 22 Alexander Toresson 2007-01-22 06:50:41 CET
I'll rerun it with G_DEBUG=gc-friendly when I come home again later today.
Comment 23 Benedikt Meurer editbugs 2007-01-22 09:18:07 CET
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!
Comment 24 Brian J. Tarricone (not reading bugmail) 2007-01-22 11:03:45 CET
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?
Comment 25 Brian J. Tarricone (not reading bugmail) 2007-01-22 11:12:49 CET
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
Comment 26 Benedikt Meurer editbugs 2007-01-22 11:44:56 CET
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.
Comment 27 Brian J. Tarricone (not reading bugmail) 2007-01-22 11:50:12 CET
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?
Comment 28 Benedikt Meurer editbugs 2007-01-23 16:42:09 CET
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.
Comment 29 Alexander Toresson 2007-01-23 19:19:36 CET
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.
Comment 30 Alexander Toresson 2007-01-23 19:26:03 CET
I suspect it's a memory management problem, as every time I rerun it in gdb, it crashes in a different location.
Comment 31 Brian J. Tarricone (not reading bugmail) 2007-01-23 20:13:00 CET
(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.
Comment 32 Alexander Toresson 2007-01-23 20:56:32 CET
(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)
Comment 33 Alexander Toresson 2007-01-23 20:57:25 CET
Created attachment 959 
valgrind log with no leak :)
Comment 34 Brian J. Tarricone (not reading bugmail) 2007-01-23 21:20:40 CET
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
Comment 35 Brian J. Tarricone (not reading bugmail) 2007-01-23 21:26:11 CET
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.
Comment 36 Alexander Toresson 2007-01-24 15:08:35 CET
Created attachment 961 
valgrind log now run with --num-callers=50
Comment 37 Brian J. Tarricone (not reading bugmail) 2007-03-07 06:25:36 CET
*** Bug 2986 has been marked as a duplicate of this bug. ***
Comment 38 Brian J. Tarricone (not reading bugmail) 2007-05-08 17:01:10 CEST
Pretty sure we fixed this with the libxfce4util changes in 4.4.1.
Comment 39 Brian J. Tarricone (not reading bugmail) 2007-09-05 17:43:31 CEST
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.
Comment 40 Brian J. Tarricone (not reading bugmail) 2007-09-05 17:44:06 CEST
*** Bug 3314 has been marked as a duplicate of this bug. ***
Comment 41 Brian J. Tarricone (not reading bugmail) 2007-09-05 17:50:15 CEST
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.
Comment 42 Andrew 2007-09-05 21:19:20 CEST
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
Comment 43 Tino Keitel 2007-09-06 15:00:31 CEST
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
Comment 44 Brian J. Tarricone (not reading bugmail) 2007-09-08 22:49:31 CEST
*** Bug 3448 has been marked as a duplicate of this bug. ***
Comment 45 Brian J. Tarricone (not reading bugmail) 2007-09-08 23:16:43 CEST
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...
Comment 46 Mathias Brodala 2007-09-09 00:08:48 CEST
(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.
Comment 47 Brian J. Tarricone (not reading bugmail) 2007-09-09 01:47:56 CEST
(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.
Comment 48 Mathias Brodala 2007-09-10 01:45:49 CEST
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.
Comment 49 Brian J. Tarricone (not reading bugmail) 2007-10-25 22:47:38 CEST
(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.
Comment 50 Mathias Brodala 2007-10-26 12:42:17 CEST
(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.
Comment 51 Yves-Alexis Perez editbugs 2008-02-28 11:58:49 CET
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.
Comment 52 Brian J. Tarricone (not reading bugmail) 2008-02-28 12:47:11 CET
(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.
Comment 53 Yves-Alexis Perez editbugs 2008-02-28 20:39:18 CET
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).
Comment 54 Brian J. Tarricone (not reading bugmail) 2008-02-28 22:02:27 CET
(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.
Comment 55 Yves-Alexis Perez editbugs 2008-02-29 07:03:06 CET
(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?
Comment 56 Brian J. Tarricone (not reading bugmail) 2008-02-29 18:45:28 CET
(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.
Comment 57 Yves-Alexis Perez editbugs 2008-03-01 14:54:13 CET
Created attachment 1533 
with debug symbols (except thunar related stuff)
Comment 58 Eric Koegel editbugs 2014-03-30 18:40:17 CEST
xfdesktop git shows no big leaks on F5 and this isn't hasn't been reported for 4.10. Closing bug report.

Bug #2427

Reported by:
Jani Monoses
Reported on: 2006-10-13
Last modified on: 2014-03-30
Duplicates (4):
  • 2595 Memory leak
  • 2986 xfdesktop uses an increasing amount of memory over time
  • 3314 memory leak in the xdesktop -reload
  • 3448 Memory leaking

People

Assignee:
Brian J. Tarricone (not reading bugmail)
CC List:
9 users

Version

Attachments

valgrind log (254.58 KB, text/plain)
2006-10-14 01:43 CEST , Brian J. Tarricone (not reading bugmail)
no flags
valgrind log, xfdesktop_file_icon_manager_add_icon() (5.91 KB, text/plain)
2007-01-21 20:24 CET , Alexander Toresson
no flags
glib memleak workaround patch (1.71 KB, patch)
2007-01-22 11:50 CET , Brian J. Tarricone (not reading bugmail)
no flags
valgrind log with no leak :) (77.43 KB, text/plain)
2007-01-23 20:57 CET , Alexander Toresson
no flags
valgrind log now run with --num-callers=50 (141.17 KB, text/plain)
2007-01-24 15:08 CET , Alexander Toresson
no flags
valgrind output for xfce-4.4.1 (92.87 KB, text/plain)
2007-09-05 21:19 CEST , Andrew
no flags
valgrind output from xfdesktop 4.4.1 (498.48 KB, text/plain)
2007-09-06 15:00 CEST , Tino Keitel
no flags
Xfdesktop running through valgrind (117.70 KB, text/plain)
2007-09-10 01:45 CEST , Mathias Brodala
no flags
valgrind log with 10 reload (192.01 KB, text/plain)
2008-02-28 11:58 CET , Yves-Alexis Perez
no flags
valgrind with 10 reloads (180.51 KB, text/plain)
2008-02-28 20:39 CET , Yves-Alexis Perez
no flags
with debug symbols (except thunar related stuff) (36.60 KB, text/plain)
2008-03-01 14:54 CET , Yves-Alexis Perez
no flags

Additional information