gnome-panel eats 50% cpu for half an hour and flickers

Happens to me too sine upgrade to Edgy.

Apparantly confirmed

It seems the process is mostly opening and parsing the applications folder in my home directory as well as the /etc/ one, and it is running gettimeofday often too.

Having straced the process for about a minute I found a few thousand gettimeofday(), thousands of time(NULL), thousands of stat64 on application folders' files such as:
    622 stat64("/usr/share/gnome/apps/Games", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
    622 stat64("/usr/share/gnome/apps/Graphics", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
    622 stat64("/usr/share/gnome/apps/Internet", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
and thousands of weird stat64's, such as:
   3731 stat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
   3732 stat64("/usr/share/gnome/apps", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
   3732 stat64("/usr/share/gnome", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
   6842 stat64("/usr/share", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
   8086 stat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
where the number before stat64 is the number of calls during this minute.
It is _heavy_ file system querying, which offcourse is madness.

Additional statistics:
15159 gettimeofday's
3726 time(NULL)
4435 read()
5025 write()
3483 poll()
7457 select()
64680 stat64()
Quite a number of system calls. In one minute totally 113061.

After some time, when gnome-panel starts working again, the system calls goes down a bit:

2601 gettimeofday's
0 time(NULL)
1494 read()
761 write()
1973 poll()
0 select()
36 stat64()

Hope this statistics helps

I get about the same calls number than Gutaf.
Can not confirm when gnome-panel cool down, as it makes my laptop shut down because of CPU heat before I even reach that point.

As a workaround, I send a signal 11 to gnome-panel, in order to interrupt it and not auto respawn it.

I can confirm, 100% CPU on edgy

Confirmed here on edgy. Has been an issue for around two weeks of updates.

Another temporary fix is to kill gam_server (as pointed out on ubuntuforums):
sudo pkill gam_server
Works for me.

Could anybody having the issue try to "gnome-session-remove gnome-panel; MENU_VERBOSE=1 GNOME_PANEL_DEBUG=1 BONOBO_ACTIVATION_DEBUG_OUTPUT=1 gnome-panel" and try to note what events make it loop? Having a backtrace with gnome-panel-dbg installed could be useful too, you can attach the panel with "gdb -p $(pidof gnome-panel)" then "thread apply all bt" to get the backtrace

I cannot note what events make the panel loop because I can't redirect the output of the terminal to a file.

Concerning the backtrace, I obtain this :

(gdb) thread apply all bt

Thread 1 (Thread -1225189712 (LWP 14482)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb758166b in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb76f4e85 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3 0xb76f51fc in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4 0xb7a23c62 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5 0x080635ef in main (argc=1, argv=0xbfcd7564) at main.c:92
#0 0xffffe410 in __kernel_vsyscall ()
(gdb)

I don't know if it's useful. If not please tell me what to do.

Vincent:
use this to pipe the output to a file "gnome-session-remove gnome-panel; MENU_VERBOSE=1 GNOME_PANEL_DEBUG=1 BONOBO_ACTIVATION_DEBUG_OUTPUT=1 gnome-panel 2> ~/Desktop/panel-debug.txt"

then use Ctrl+c to stop the process after about a minute..

unfortunantly for me, this created a 52 meg file.
I'm going through it now trying to see what might be relevent.

the "sudo pkill gam_server" doesn't help me.

I gave up trying to sort the debug output.. it's greek to me.

compressed and attached.

sudo apt-get install menu menu-xdg
update-menus

seems to have fixed it for me.

with the interesting side effect of giving me a debian menu with launchers for several programs the run in terminals as well as several that I didn't realize were installed.

Same fr me here, this is what sysprof finds out.

After trying "gnome-session-remove gnome-panel; MENU_VERBOSE=1 GNOME_PANEL_DEBUG=1 BONOBO_ACTIVATION_DEBUG_OUTPUT=1 gnome-panel 2> ~/Desktop/panel-debug.txt" and reading the output, the events "file:///etc/xdg/menus/debian-menu.menu" created, marking tree for recanonicalization" seems to make gnome-panel loops.

gnome-menus try to write to the symlink /etc/xdg/debian-menu.menu. In my system this symlink is inactive (it points to /var/lib/menu-xdg/menus/debian-menu.menu which doesn't exist).

If you delete this symlink, the menu works perfectly.

deleting the symlink works for me too

These seems to be bug #5176 cropping up again. I remember following it up in January 2006. It's also:

  http://bugzilla.gnome.org/show_bug.cgi?id=323064
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338438

Surely menu-xdg shouldn't be shipping a broken symlink in the first place. This wouldn't happen if menu-xdg depended on menu, rather than only recommending it.

Does anyone know why it is that way?

To clarify on comment 17,
/etc/xdg/menu/debian-menu.menu is the broken symlink that needs deleting, not:
/etc/xdg/debian-menu.menu, which doesn't exist.
But excellent workaround.

On Mon, Jul 31, 2006 at 10:54:07PM -0000, Jeff250 wrote:
> To clarify on comment 17,
> /etc/xdg/menu/debian-menu.menu is the broken symlink that needs deleting, not:
> /etc/xdg/debian-menu.menu, which doesn't exist.
> But excellent workaround.

A better workaround is to completely remove menu-xdg, as it isn't needed
anyway.

--
 - mdz

Yes Matt, unless it has dependencies. To me it's not really an option. Removing menu-xdg would mean to remove:
kcontrol kdelibs4c2a kicker koctave kwave libkonq4 menu-xdg tora

But the problem still exists, and this is what's so troublesome with things like gnome. The problem is that the menu flickers, and the app goes crazy just because a symlink is pointing to outer space. To me, THIS is the bug, and the 'solutions' above are hacks which 'might' work, but it doesn't solve the bug.
It is caused by bad programming, not because of vague packaging. A program 'crashing' because a symlink (which is not required by the program) doesn't exist or doesn't point to a valid file is a badly written program.
In gnome, bugs reappear year after year, and the real problem doesn't get solved (like in gconf/gsd, which is a big jar of bugs).

Btw, it's /etc/xdg/menus/debian-menu.menu, not /etc/xdg/menu/debian-menu.menu

Gustaf, nobody discuss that's a bug and that's not the right place to troll on "things like gnome" or anything else, if you don't want to be constructive please don't comment

Remove /etc/xdg/menus/debian-menu.menu works for me too.

Removing /etc/xdg/menus/debian-menu.menu works here too. Thanks for all your help.

this is still a problem in latest edgy (I dist-upgraded from dapper yesterday).

Removing /etc/xdg/menus/debian-menu.menu fixed for me for now.

http://bugzilla.gnome.org/show_bug.cgi?id=323064 says that there is a patch out there to make gnome-menus use gnome-vfs which apparently would avoid this bug.

For me, removing the file helps only temporarily. With the file, I get high cpu load immediately, without it only after some time.

for me, gp was eating up to 90 %
removing menu-xdg solved the issue, though it forced me to also remove the side kubuntu packages. As some others, I'd like to keep both. So a long term solution would be appreciated ;-)

Also note that it had side effect, like the one mentionned in lp bug 57516...

Removing /etc/xdg/menus/debian-menu.menu worked for me as well

I see this issue on my system as well. The way I deal with it when I'm running on battery is to attach to it using gdb. From there, I can just break and have it not resume. This, of course, means that I lose my panel functionality, though.

I will remove /etc/xdg/menus/debian-menu.menu, but I'd like to voice my agreement that removing the file is NOT an appropriate solution to this bug. gnome-panel should be robust enough to deal with any such input without causing the kind of nastiness manifested in this bug. Even if menu-xdg is not installed by default, I should be able to install it (for no particular reason, perhaps just because I want to break gnome-panel!) without having this problem crop up again.

Confirmed here on edgy, confirmed workarounds do work, but still.. that's not the answer to the problem.

I had this problem but a recent update seems to have cured it.

gnome-panel is now running normally.

Does anyone still have the problem, with an up-to-date Edgy, and without any tweaking ?

This problem hasn't showed up for me since last week. I've installed a few
edgy boxes from dailies since then.

It appears to be ok here, too.

Ok, I'll assume it's fixed then. Feel free to reopen if you find the problem remains.

This bug is NOT fixed; I've worked around it by changing menu-xdg not to trigger the bug. I'm setting its importance to Low since it won't affect many users now.

menu-xdg (0.2.3ubuntu1) edgy; urgency=low

  * Rather than shipping a broken symlink, create it when update-menu is run
    (workaround for LP#52405)

 -- Matt Zimmerman <email address hidden> Wed, 23 Aug 2006 03:48:24 -0700

Just want to add that contrary to what I said in comment 28, the workaround works for me too. Don't know what was wrong previously.

This workaround does not work for me as i dont have the following file on my system: /etc/xdg/menus/debian-menu.menu on my system.

$ uname -a
Linux srasul-laptop 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux

so this problem is still occuring on my Edgy

Can this be dup'ed to bug #36272?

No, the other bug has been fixed, that one might be fixed with the new gamin package now as well though, would be nice if somebody could try to trigger that bug on feisty

Problem still exists on Ubuntu 7.10 (Gutsy Gibbon). Deleting /etc/xdg/menus/debian-menu.menu is not an option, since it doesn't exist.

does anybody get the issue on gutsy or hardy?

untagging the bug, there is no recent duplicate so the bug is likely fixed or the new versions don't trigger it, not an hardy issue anyway

> untagging the bug, there is no recent duplicate so the bug is likely fixed or the new versions don't trigger it, not an hardy issue anyway
No sorry, the bug is not fixed. I can confirm this bug for Ubuntu 7.10. If anyone is interested, I'll provide more info on my system configuration on request.

I can confirm it as well for ubuntu 7.10.

I can add that the problem started to occur on my pc after I

1. did place the default low panel to the left and
2. changed its behaviour to autohide:yes

After that, gnome-panel will slowly eat up more and more cpu and memory, wasting 170mb RAM + 50% @2 cores after 10 minutes.
Information is from System>System Monitor.

Hello,

Just to confirm the bug in a newly updated Hardy Heron Ubuntu (Linux 2.6.22-14). I have a panel attached to the left side of the screen and after opening more than 7 applications (exact number, reproducible every time) the bar hangs and takes more than 40% of cpu (looked via system monitor)

To reproduce in your computer:

1. Right click on a panel and click "new panel"
2. Right click on the new panel and click "Properties"
3. Select option Orientation:left. and size:40 click. close
4. Right click on new left panel and click "Add to panel"
5. Look for "Window List" , select "add" and click close.
6. Open 6 programs (so that 6 icons show in the new window list)
7. Open the 7th and the panel will freeze (and munch cpu cycles like crazy )

the tasks list issue on vertical gnome-panels is an another issue, does anybody still get the cpu usage issue in hardy?

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

It looks like abia and obaqueiro are seeing bug 187540. The OP and others may be seeing something different. If they're seeing the same problem, then this should be marked as a dup of 187540. Otherwise, I agree with Pedro, we need more specific details on how it's different.