GNOME Bugzilla – Bug 660423
CPU at 100%, sched_yield
Last modified: 2011-11-15 12:00:18 UTC
Sometimes I see gnome-volume-manager using 100% of one CPU. Doing a strace shows the following trace: 09:26:52.957842 sched_yield() = 0 09:26:52.958008 sched_yield() = 0 09:26:52.958085 sched_yield() = 0 09:26:52.958149 sched_yield() = 0 09:26:52.958207 sched_yield() = 0 09:26:52.958262 sched_yield() = 0 09:26:52.958315 sched_yield() = 0 09:26:52.958369 sched_yield() = 0 09:26:52.958423 sched_yield() = 0 09:26:52.958475 sched_yield() = 0 09:26:52.958528 sched_yield() = 0 09:26:52.958581 sched_yield() = 0 09:26:52.958634 sched_yield() = 0 09:26:52.958686 sched_yield() = 0 09:26:52.958740 sched_yield() = 0 09:26:52.958793 sched_yield() = 0 09:26:52.958846 sched_yield() = 0 A gdb backtrace looks as follows: (gdb) bt
+ Trace 228635
Although I've not been able to reproduce consistenly, I've been hit a fair by this bug afair amount of time in the past weeks. The only work around I've found is to kill the process. It seems that gnome-volume-manager is not required to run Gnome 3, so I will remove it from my system, but there still might be a bug inside glib that needs to be fixed (gthread or gio?) ? I'm running glib 2.28.6 (Debian 2.28.6-3).
Might be a duplicate of #627724 (same backtrace).
fwiw, the yield call is no longer present in glib 2.30
We need the output of "t a a bt", not just "bt", because the former gives us all threads. See https://live.gnome.org/GettingTraces
Colin: I initially had only done a 'bt', I then did a "thread all apply bt" which, unless I wasn't properly awake, did not show more than one thread.
I believe this only affects 2.28; now that GNOME 3.0 has reached Debian testing, GNOME 3.2 (including GLib 2.30) should hopefully follow soon, which should solve this. Mathias Hasselmann recently noticed that GDBus 2.28's implementation of waiting for the worker thread to start isn't safe, because the worker thread (which sets data->done) doesn't use a memory barrier to ensure that the write becomes visible to the user thread (which reads it in the snippet he quotes here): 11:13 < hasselmm> 11:10:35> hmm.... 11:13 < hasselmm> 11:10:39> " /* wait for the user code to run.. hmm.. probably use a condition variable instead */ 11:13 < hasselmm> 11:10:40> while (!data->done) 11:13 < hasselmm> 11:10:40> g_thread_yield (); 11:13 < hasselmm> 11:10:40> " 11:13 < hasselmm> 11:11:27> hah, mutable is not volatile ... 11:16 <@smcv> hasselmm: data->done should be atomic access at least, yeah In the GLib packages for Maemo (theoretically based on GLib 2.28, but with increasing amounts of 2.30), I've done a backport of Colin's commit 7ed328a from 2.30, which should fix this.
If this is indeed solved by Colin's commit 7ed328a, then it's a dup of Bug #651650.
*** This bug has been marked as a duplicate of bug 651650 ***