! 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 !
xfdesktop and xfce4-menu-plugin memory leaks
Status:
RESOLVED: WONTFIX
Product:
Libxfce4menu
Component:
General

Comments

Description Kevin Fenzi 2008-01-23 00:31:11 CET
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
Comment 1 Kevin Fenzi 2008-01-23 00:32:15 CET
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. 
Comment 2 Brian J. Tarricone (not reading bugmail) 2008-01-23 00:52:38 CET
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.
Comment 3 Kevin Fenzi 2008-01-23 00:55:48 CET
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.
Comment 4 Ray Van Dolson 2008-01-23 02:14:11 CET
Created attachment 1497 
valgrind output

Same as https://bugzilla.redhat.com/attachment.cgi?id=292574 from the Fedora bug.
Comment 5 Kevin Fenzi 2008-02-21 03:31:16 CET
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. 
Comment 6 Brian J. Tarricone (not reading bugmail) 2008-02-21 04:04:33 CET
Haven't really had time lately, sorry.
Comment 7 Kevin Fenzi 2008-02-21 04:16:26 CET
No worries. Let me know if I can gather any more info. 
Comment 8 Brian J. Tarricone (not reading bugmail) 2008-02-24 01:58:26 CET
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...
Comment 9 Kevin Fenzi 2008-02-24 16:37:03 CET
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?
Comment 10 Brian J. Tarricone (not reading bugmail) 2008-02-26 08:36:44 CET
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.
Comment 11 Kevin Fenzi 2008-03-02 02:32:37 CET
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!
Comment 12 Yves-Alexis Perez editbugs 2008-04-29 13:11:04 CEST
(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.
Comment 13 Lionel Elie Mamane 2008-05-03 07:01:23 CEST
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?
Comment 14 Yves-Alexis Perez editbugs 2008-05-03 08:06:54 CEST
There are some info on how to do this on bug #2427
Comment 15 Lionel Elie Mamane 2008-05-03 08:46:07 CEST
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?
Comment 16 Yves-Alexis Perez editbugs 2008-05-03 08:49:19 CEST
(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)
Comment 17 Lionel Elie Mamane 2008-05-03 09:46:30 CEST
(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.
Comment 18 Lionel Elie Mamane 2008-05-03 10:06:09 CEST
Created attachment 1613 
Valgrind output - probably faulty
Comment 19 Lionel Elie Mamane 2008-05-03 10:06:48 CEST
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?
Comment 20 Lionel Elie Mamane 2008-05-03 10:51:45 CEST
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
Comment 21 Lionel Elie Mamane 2008-05-03 10:54:46 CEST
Ah, that was my (stupid) error, the wrapper reexecutes itself instead of the .orig file. Sorry for the noise.
Comment 22 Lionel Elie Mamane 2008-05-03 10:56:55 CEST
Created attachment 1614 
Valgrind output
Comment 23 Brian J. Tarricone (not reading bugmail) 2008-05-03 21:21:00 CEST
(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.
Comment 24 Yves-Alexis Perez editbugs 2008-05-27 06:16:30 CEST
Created attachment 1643 
Valgrind output

Another valgrind output, from Santiago Ruano Rincón on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376177
Comment 25 Brian J. Tarricone (not reading bugmail) 2008-05-27 06:26:04 CEST
(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.
Comment 26 Yves-Alexis Perez editbugs 2008-05-27 21:09:49 CEST
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...
Comment 27 Yves-Alexis Perez editbugs 2008-05-27 21:10:35 CEST
Created attachment 1646 
Script to reload and refresh menu

This script reload xfdesktop, popups the menu and refresh it endlessly.
Comment 28 Yves-Alexis Perez editbugs 2008-05-29 05:46:56 CEST
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.
Comment 29 Brian J. Tarricone (not reading bugmail) 2008-05-29 06:35:37 CEST
(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.
Comment 30 Lionel Elie Mamane 2008-09-01 11:54:22 CEST
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.
Comment 31 Brian J. Tarricone (not reading bugmail) 2008-09-01 17:01:10 CEST
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.
Comment 32 David Mohr 2008-12-17 17:47:28 CET
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.
Comment 33 David Mohr 2008-12-17 19:31:41 CET
Created attachment 2044 
valgrind leak log, uncompressed!
Comment 34 David Mohr 2008-12-17 19:36:05 CET
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.
Comment 35 Tomasz Paweł Gajc 2009-02-16 06:09:23 CET
Looks like this is still a problem with xfce-4.5.99.1

https://qa.mandriva.com/show_bug.cgi?id=47835
Comment 36 David Mohr 2009-02-20 05:21:52 CET
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.
Comment 37 David Mohr 2009-02-20 16:54:27 CET
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.
Comment 38 Jannis Pohlmann editbugs 2009-02-20 17:17:09 CET
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.
Comment 39 Nick Schermer editbugs 2014-12-03 09:19:22 CET
Close bug reports of archived products.

Bug #3812

Reported by:
Kevin Fenzi
Reported on: 2008-01-23
Last modified on: 2014-12-03

People

Assignee:
Jannis Pohlmann
CC List:
6 users

Version

Version:
4.5.90 (4.6 alpha)

Attachments

valgrind output (153.71 KB, text/plain)
2008-01-23 02:14 CET , Ray Van Dolson
no flags
Valgrind output - probably faulty (21.12 KB, text/plain)
2008-05-03 10:06 CEST , Lionel Elie Mamane
no flags
Valgrind output (64.78 KB, text/plain)
2008-05-03 10:56 CEST , Lionel Elie Mamane
no flags
Valgrind output (175.76 KB, text/plain)
2008-05-27 06:16 CEST , Yves-Alexis Perez
no flags
Valgrind output (122.19 KB, text/plain)
2008-05-27 21:09 CEST , Yves-Alexis Perez
no flags
Script to reload and refresh menu (341 bytes, application/octet-stream)
2008-05-27 21:10 CEST , Yves-Alexis Perez
no flags
Yet another valgrind log (149.45 KB, text/plain)
2008-05-29 05:46 CEST , Yves-Alexis Perez
no flags
Valgrind output for menu plugin (93.45 KB, text/plain)
2008-09-01 11:54 CEST , Lionel Elie Mamane
no flags
valgrind leak log (9.43 KB, application/x-bzip)
2008-12-17 17:47 CET , David Mohr
no flags
valgrind leak log, uncompressed! (201.25 KB, text/plain)
2008-12-17 19:31 CET , David Mohr
no flags
Patch to fix the memory leak (3.91 KB, patch)
2009-02-20 16:54 CET , David Mohr
no flags

Additional information