Bugzilla – Bug 307862
main-menu uses 100% CPU when unsuspending, takes a long time to respond
Last modified: 2008-04-09 10:15:53 UTC
I'm seeing something like the old main-menu problems again in beta2. On a couple of occasions it seems to spin out of control and consume cpu. It may be related to thumbnailing (it was in the past) but I'm not aware of an easy way to test that hypothesis.
Larry, Do you see this in conjunction with STR and/or NM activity? I see this if I STR for a period of time, then when waking up the laptop, Slab will consumer 40-50% CPU while NM is trying to establish a network connection. NM will not succeed until I kill Slab and restart it.
SMP? i586 or x86_64? I suppose you could clear your recently used documents (perhaps by logging out, logging in through the console, and renaming ~/.recently-used.xbel), but that would only be a useful trick if you could reproduce the problem reliably, at least with a given set of recently used documents.
i can reproduce it reliably: suspend2disk/suspend2ram then resume with a small number of documents (both recent and in ~/Documents: florin@florin-laptop:~/Documents> ls|wc -l gives 14). i686, smp,Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz.
Looks like everyone's questions are answered. Unless someone has a question for me (and I don't see any pending), I'm clearing NEEDINFO.
i belive that bug 300289 is identical to this one and one of them should be marked as duplicate.
OK, now I have a question. Larry: are you seeing this when unsuspending?
This happens on my box (x86-64, NM enabled) after resuming. It does not matter whether the system was suspended to disk or to RAM. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4127 thoenig 25 0 413m 164m 23m R 91 16.5 8:19.40 main-menu
Some time later (leaving the system unused/idle): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4127 thoenig 25 0 683m 429m 22m R 95 43.2 76:09.42 main-menu This renders my system unusable. Raising to blocker.
Attaching to the process with gdb, getting a backtrace: (gdb) bt #0 0x00002b8328b19c45 in g_slist_find () from /usr/lib64/libglib-2.0.so.0 #1 0x00002b8322b2bcff in ?? () from /usr/lib64/libdbus-glib-1.so.2 #2 0x00002b8322b2c044 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #3 0x00002b83284923d0 in g_object_newv () from /usr/lib64/libgobject-2.0.so.0 #4 0x00002b8328492de6 in g_object_new_valist () from /usr/lib64/libgobject-2.0.so.0 #5 0x00002b8328493011 in g_object_new () from /usr/lib64/libgobject-2.0.so.0 #6 0x00002b8322b293a1 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #7 0x000000000041289e in gnome_vfs_volume_unref () #8 0x00002b8322b2a33c in ?? () from /usr/lib64/libdbus-glib-1.so.2 #9 0x00002b832848dd2f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #10 0x00002b83284a01cd in ?? () from /usr/lib64/libgobject-2.0.so.0 #11 0x00002b83284a1c25 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #12 0x00002b83284a2013 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #13 0x00002b8322b2b13a in ?? () from /usr/lib64/libdbus-glib-1.so.2 #14 0x00002b8323940f4c in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #15 0x00002b8322b23fb5 in ?? () from /usr/lib64/libdbus-glib-1.so.2 #16 0x00002b8328afe064 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #17 0x00002b8328b0135d in ?? () from /usr/lib64/libglib-2.0.so.0 #18 0x00002b8328b01657 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #19 0x00002b832132c3a6 in bonobo_main () from /usr/lib64/libbonobo-2.so.0 #20 0x00002b832132a871 in bonobo_generic_factory_main_timeout () from /usr/lib64/libbonobo-2.so.0 #21 0x00002b831db44314 in panel_applet_factory_main_closure () from /usr/lib64/libpanel-applet-2.so.0 #22 0x000000000040d5bd in gnome_vfs_volume_unref () #23 0x00002b8328db4b54 in __libc_start_main () from /lib64/libc.so.6 #24 0x0000000000409589 in gnome_vfs_volume_unref () #25 0x00007fff8d187308 in ?? () #26 0x0000000000000000 in ?? ()
Adjusting summary, releasing NEEDINFO.
It's somewhere stuck in g_slist_find: Program received signal SIGINT, Interrupt. 0x00002b8328b19c45 in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) step Single stepping until exit from function g_slist_find, which has no line number information. Quit (gdb) stepi 0x00002b8328b19c4b in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) stepi 0x00002b8328b19c4e in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) stepi 0x00002b8328b19c42 in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) stepi 0x00002b8328b19c45 in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) stepi 0x00002b8328b19c47 in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb) stepi 0x00002b8328b19c4b in g_slist_find () from /usr/lib64/libglib-2.0.so.0 (gdb)
not blocking
*** Bug 310475 has been marked as a duplicate of this bug. ***
*** Bug 300289 has been marked as a duplicate of this bug. ***
This seems to be an issue with NetworkManager sending hundreds of DBus messages after unsuspending and when switching networks. I have a solution ready, but am unable to test it as I am not able to get suspending or network switching to work in beta 3+. Am working on that now.
Created attachment 173160 [details] new main-menu package I am not able to fully replicate this bug. On Beta3+ when I suspend/resuspend or switch networks the main-menu is receiving dozens of duplicate DBus messages and showing slight spikes in CPU usage. This is contrasted with behavior I have noticed before where the main-menu receives hundreds of duplicate DBus messages and shows 100% CPU usage. This package has a fix to ignore duplicate messages instead of trying to process them. Hopefully that will fix the problem. If, however, simply receiving the messages causes the increased CPU usage then this will not fix the problem. As I cannot fully replicate the problem I am not submitting this to autobuild yet, but would like anyone who can reproduce this fully to try out this package and see if it helps. 64 bit packages can be found at http://w3.suse.de/~jimmyk/gnome-main-menu/STABLE/v0.9.8-87/. Thanks! Jim
I replicated the suspend behavior and then tried out the new package and it looks like it fixes the problem for me. The main-menu seemed to behave as expected now.
Reproduced the high utilization then tested with new package and it appears to have fixed the utilization issues.
This has been submitted to autobuild. Thanks!
Sooo... shouldn't we also fix NetworkManager so it doesn't send hundreds of messages?
;-) Jim, can you tell whether the duplicate messages are killswitch related -- the ones I'm referring to in bug #310509?
For reference, the upstream svn commit that fixes this is r354.
Created attachment 206910 [details] This is the patch that was committed upstream, and is in our 10.3 and 11.0 packages
And we already had a bug about this for SLED10: bug #191903
Submitted for sle10-sp2 as well: * Tue Apr 08 2008 - federico@novell.com - Added gnome-main-menu-bnc307862-fix-cpu-hog-when-unsuspending.diff as a backport for SLED10-SP2 for the fix to https://bugzilla.novell.com/show_bug.cgi?id=307862 - gnome-main-menu uses 100% CPU and takes a long time to respond after unsuspending a laptop.