Memory leak in xfce4-menu-plugin

[trippyd]

Binary package hint: xfce4-panel

I am using XUbuntu Edgy, up to date as of this morning. I have googled around and haven't found a good answer for this one, so I thought I would try here.

The system:
Dell Optiplex, 3gig HT CPU
1 Gig ram.

Basically, from a restart (of the computer or X), xfce4-menu-plug and xfce4-panel will start out taking around 1% of the system memory each. As time passes, whether I am doing anything or not, this number will slowly grow.

For example, I have been away from my work PC for 3 days with the new years holiday/weekend, and when I arrived this morning, each process was taking 12-13% of my system memory. I figured out that these two guys (xfce4-menu-plug and xfce4-panel) were the culprits one time when they were each taking 25% of my system memory (half of my system memory between them). It doesn't seem to be related to what I have open or what I am doing, the number just slowly grows.

This isn't an end of the world kind of problem, I just have to restart X to get them down to a more respectable level, but it is pretty annoying.

Any thoughts?

Thanks,
D

[Cody A.W. Somerville (cody-somerville)]

I can confirm this.

[Jani Monoses (jani)]

is this still an issue on feisty?

[Jani Monoses (jani)]

not confirmed on feisty, so closing

[trippyd (trippyd)]

Confirmed on feisty, xfce-panel no longer grows, but xfce-menu-plug still has the issue, my system has been up for 2 days, it started out taking 1%, and is currently using 7.8%, with nothing open.

[afoglia (afoglia)]

I also can confirm this as well in Feisty. xfce-menu-plugin is using 12.9% of my memory after my computer has been left on for 8 days. (Sizes reported by htop: 542M virtual, 133M resident, 7036 shared) It's the biggest memory user by a factor of 2. (Second is kazehakase with 6+ tabs open.)

[Zoro (daniel-hunt4)]

I can also confirm this in Feisty, and annoying is just not the word for it :)
Has anyone found a way around this problem?

[tuna (avtuunainen)]

I can still confirm this on gutsy. Also, this is fixed on xfce 4.4.2. I suggested that it should be backported, and the backport people said it should be in the updates repository instead.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Lionel: what can we do for this one ? Can we do a SRU ?

Marking this as fix committed as a fix is available in 4.4.2

[Lionel Le Folgoc (mrpouit)]

I'm not sure whether that's fixed in xfdesktop 4.4.2-1ubuntu1 or not (upstream changelog only says: "Some minor memory leak fixes (some still remain, likely)."). Could someone test and confirm?

[Toni (topinet)]

i'm also having this problem with ubuntu 7.10 gutsy and xfdesktop4 (version 4.4.1-5ubuntu3)

after two days of my computer running, xfce4-menu-plugin uses more than 1GB by itself, the only solution is restart it.

[Iain Parris (ipv2)]

Ditto. I had the exact same problem in Xubuntu 7.10, with xfdesktop4 (4.4.1) - massive memory leaks. Starting out using a few MB of physical memory; after ~5 days, hundreds of MB.

As requested by Lionel, I've now installed xfdesktop4 (4.4.2-2ubuntu1) from the hardy repository. I'll report back in a few days, on if major memory leaks still occur.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Closing the xfce4-panel task.

[Zoro (daniel-hunt4)]

Closed?

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Zoro: as far as I know this is a bug in xfdesktop4 which might be fixed in 4.4.2, xfce4-planel is not known to be the source of this memory leak.

[Iain Parris (ipv2)]

OK. As I wrote above, I've been running xfdesktop4 (4.4.2-2ubuntu1) since Thursday, as per Lionel's request.

There is still a massive memory leak. xfdesktop and xfce4-menu-plugin each still leak memory horribly; xfce4-panel does not (as said in the posts above).

It is interesting to note that memory grows (almost perfectly) linearly - with time. I noted down memory usage daily, and could draw a straight line graph (after converting dates to UNIX times...)

xfdeskop leaks memory at 35.2MB/day.
xfce4-menu-plugin leaks memory at 35.5MB/day.

It is also interesting how close those two figures are...

My system doesn't swap. The above figures are all for physical RAM, as reported by GNOME System Monitor.

[nirik (kevin-scrye)]

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

[nirik (kevin-scrye)]

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.

[Brian Tarricone (kelnos)]

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.

[nirik (kevin-scrye)]

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.

[nirik (kevin-scrye)]

Greetings. I am the Fedora Xfce mantainer.

Some folks over here and seeing this as well.
See:

https://bugzilla.redhat.com/show_bug.cgi?id=428662

I filed an upstream bug with Xfce:

http://bugzilla.xfce.org/show_bug.cgi?id=3812

[Ray Van Dolson (rvandolson)]

Created attachment 1497
valgrind output

Same as https://bugzilla.redhat.com/attachment.cgi?id=292574 from the Fedora bug.

[nirik (kevin-scrye)]

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.

[Brian Tarricone (kelnos)]

Haven't really had time lately, sorry.

[nirik (kevin-scrye)]

No worries. Let me know if I can gather any more info.

[Brian Tarricone (kelnos)]

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...

[nirik (kevin-scrye)]

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?

[Brian Tarricone (kelnos)]

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.

[nirik (kevin-scrye)]

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!

[Yves-Alexis Perez (corsac)]

(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.

[Lionel Elie Mamane (lionel-mamane)]

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?

[Yves-Alexis Perez (corsac)]

There are some info on how to do this on bug #2427

[Lionel Elie Mamane (lionel-mamane)]

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?

[Yves-Alexis Perez (corsac)]

(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)

[Lionel Elie Mamane (lionel-mamane)]

(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.

[Lionel Elie Mamane (lionel-mamane)]

Created attachment 1613
Valgrind output - probably faulty

[Lionel Elie Mamane (lionel-mamane)]

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?

[Lionel Elie Mamane (lionel-mamane)]

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", "-...

[Lionel Elie Mamane (lionel-mamane)]

Ah, that was my (stupid) error, the wrapper reexecutes itself instead of the .orig file. Sorry for the noise.

[Lionel Elie Mamane (lionel-mamane)]

Created attachment 1614
Valgrind output

[Brian Tarricone (kelnos)]

(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.

[bsh (bsh)]

I can confirm this on feisty, i'm running ubuntu 7.04 feisty with xfce 4.4 from the repos.
menu plugin uses like 80-90mb after a 2 weeks uptime.
the other leak i found is in the xfce-sensors-applet, it's even worse.

[Yves-Alexis Perez (corsac)]

Created attachment 1643
Valgrind output

Another valgrind output, from Santiago Ruano Rincón on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376177

[Brian Tarricone (kelnos)]

(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.

[Yves-Alexis Perez (corsac)]

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...

[Yves-Alexis Perez (corsac)]

Created attachment 1646
Script to reload and refresh menu

This script reload xfdesktop, popups the menu and refresh it endlessly.

[Yves-Alexis Perez (corsac)]

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.

[Brian Tarricone (kelnos)]

(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.

[Lionel Elie Mamane (lionel-mamane)]

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.

[Brian Tarricone (kelnos)]

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.

[Jean-Christophe Dubois (jcd)]

This is still not fixed. I am running xubuntu 8.10 at the moment and may xfce4-menu-plug is using 232 MB as I write this message.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27023 jcd 20 0 428m 232m 8924 S 0.0 24.5 318:48.74 xfce4-menu-plug

[David Mohr (bugs-da)]

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.

[David Mohr (bugs-da)]

Created attachment 2044
valgrind leak log, uncompressed!

[David Mohr (bugs-da)]

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.

[markor (markoresko)]

I am using Xubuntu Hardy/8.04.1 LTS amd64/x86_64 version
My xfce4-menu-plugin can grow to insane values, sometimes over 200MB
Currently while I am writing this it is 148MB since I am runing it few days now.
(As seen from System monitor)
I removed menu plugin from panel and added it again few days ago and
upon start it takes about 12MB..

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23152 user 20 0 429m 166m 14m S 1 9.4 9:58.29 xfce4-menu-plug

[Tpg-b (tpg-b)]

Looks like this is still a problem with xfce-4.5.99.1

https://qa.mandriva.com/show_bug.cgi?id=47835

[David Mohr (bugs-da)]

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.

[David Mohr (bugs-da)]

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.

[Jannis Pohlmann (jannis-xfce)]

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.

[yaztromo (tromo)]

Apparently this is now fixed in XFCE 4.6 final.

[Lionel Le Folgoc (mrpouit)]

Indeed, since xfdesktop now uses libxfce4menu.

[Nikola M (nikolam)]

What should we do about fixing this bug in LTS and other supported releases
since I just jame back from 20+ days trip and this is what xfce-menu-plugin has been doing for some time.. Leaking!:
 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12506 nikola 20 0 4225m 901m 11m S 0 47.8 232:40.75 xfce4-menu-plug

[Charlie Kravetz (cjkgeek)]

Both Xfce and Debian have open bugs for this issue.

[unixnewbie (darfsten)]

i'd like to add to this also. i am running mythbuntu jaunty jackalope and it uses xfce4-panel. version info here:
Package: xfce4-panel
State: installed
Automatically installed: yes
Version: 4.6.0-1ubuntu1
Priority: optional
Section: universe/x11
Maintainer: Xubuntu Developers <email address hidden>
Uncompressed Size: 2019k
Depends: libatk1.0-0 (>= 1.20.0), libc6 (>= 2.4), libcairo2 (>= 1.2.4), libexo-0.3-0 (>= 0.3.100), libfontconfig1 (>=
         2.4.0), libfreetype6 (>= 2.3.5), libglib2.0-0 (>= 2.18.0), libgtk2.0-0 (>= 2.15.0), libice6 (>= 1:1.0.0),
         libpango1.0-0 (>= 1.22.0), libsm6, libstartup-notification0 (>= 0.8-1), libwnck22 (>= 2.22.0), libx11-6,
         libxfce4util4 (>= 4.6.0), libxfcegui4-4 (>= 4.6.0), zlib1g (>= 1:1.1.4), exo-utils
Conflicts: xubuntu-default-settings (< 0.48)
Replaces: xubuntu-default-settings (< 0.48)
Description: The Xfce4 desktop environment panel
 This is the panel provided by the Xfce4 desktop project. If you want a multi-functional panel that can even handle
 plugins and the like, xfce4-panel might be worth a try.
Homepage: http://www.xfce.org/

when I ran top, it showed this:
   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7560 daniel 20 0 21808 2684 1556 S 0.3 1.1 2:14.58 xfce4-panel

please let me know how can I solve this issue as my system only has 256mb ram and it's my main file server and mythtv server. any help would be much appreciated.

[Nikola M (nikolam)]

I would suggest to remove menu applet from the panel when not in use. and add it when needed.
Or, like me, to remove it from panel and add it to it every few days if machine is used interactively for a long time and not restarted.
Also you can turn on "Show desktop menu on right click" in desktop preferences, to get program menu right clicking of desktop, instead of letting it leak when active all the time.

[8-nick (8-nick)]

Close bug reports of archived products.