After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645877 - commit 14d7db1 causes cpu spinning and other bus weirdness
commit 14d7db1 causes cpu spinning and other bus weirdness
Status: RESOLVED DUPLICATE of bug 645746
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal blocker
: 0.10.33
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-28 00:09 UTC by Jonathan Matthew
Modified: 2011-04-07 11:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan Matthew 2011-03-28 00:09:37 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.
Comment 1 Jonathan Matthew 2011-03-28 09:33:09 UTC
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);
Comment 2 Jonathan Matthew 2011-03-28 12:15:23 UTC
No, replacing that code with a different approach that doesn't remove and re-add the bus watch doesn't solve the problem.
Comment 3 Jonathan Matthew 2011-03-29 10:02:02 UTC
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.
Comment 4 Tim-Philipp Müller 2011-04-04 09:58:42 UTC
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
Comment 5 Jonathan Matthew 2011-04-05 01:23:18 UTC
Looks good so far.  I'll pay attention to it for the next couple of days to be sure.
Comment 6 Jonathan Matthew 2011-04-07 11:47:13 UTC
yeah, this is fixed enough for me.

*** This bug has been marked as a duplicate of bug 645746 ***