GNOME Bugzilla – Bug 645877
commit 14d7db1 causes cpu spinning and other bus weirdness
Last modified: 2011-04-07 11:47:13 UTC
I haven't looked into this much, but I'm pretty sure the cpu spinning problem I'm seeing in rhythmbox is caused by this recent change to GstBus. It's most often triggered when restarting a pipeline from READY, often results in gst_bus_timed_pop returning NULL instantly, and always involves the main loop spinning and idle sources at normal priority not being called. Adding any amount of debug output (either in gstreamer or rb) seems to be enough to hide it. Once triggered, attaching gdb and setting a breakpoint in gst_bus_source_dispatch shows that's where the main loop is spending its time.
possibly related to this code in rhythmbox: /* prevent messages from being processed by the main thread while we're starting the sink */ g_source_remove (player->priv->bus_watch_id); ret = start_sink_locked (player, &messages, error); add_bus_watch (player);
No, replacing that code with a different approach that doesn't remove and re-add the bus watch doesn't solve the problem.
Just saw this happen when starting the pipeline for the first time, so it's not related to restarting sinks or anything like that. Also, I've reverted commit 14d7db1 on one machine, and there I haven't seen this happen in two days where normally I would have seen it multiple times, so I'm fairly sure this change introduced the problem.
Does this fix it? commit 7c6d9c2725a9632fbd96fd41b60ed814649d3bec Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Mon Apr 4 03:33:46 2011 +0200 gstpoll: retry reading the control socket to release properly all wakeups if set->control_pending is set to 0 but we didn't not succed reading the control socket, future calls to gst_poll_wait() will be awaiken by the control socket which will not be released properly because set->control_pending is already 0, causing an infinite loop. https://bugzilla.gnome.org/show_bug.cgi?id=645746
Looks good so far. I'll pay attention to it for the next couple of days to be sure.
yeah, this is fixed enough for me. *** This bug has been marked as a duplicate of bug 645746 ***