[Bug 741355] playbin: deadlock

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=741355

Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.5.1

--- Comment #29 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
All three patches pushed. Thanks for the testing.

commit a2ee84fa80cde8174a2e44258b3b57e94c28216e
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Thu Feb 5 12:07:50 2015 +0000

    decodebin: fix deadlock between downward state change and pad addition

    If caps on a newly added pad are NULL, analyze_new_pad will try to
    acquire the chain lock to add a probe to the pad so the chain can
    be built later. This comes from the streaming thread, in response
    to headers or other buffers causing this pad to be added, so the
    stream lock is taken.

    Meanwhile, another thread might be destroying the chain from a
    downward state change. This will cause the chain to be freed with
    the chain lock taken, and some elements are set to NULL here, which
    can include the parser. This causes pad deactivation, which tries
    to take the element's pad's stream lock, deadlocking.

    Fix this by keeping track of which elements need setting to NULL,
    and only do this after the chain lock is released. Only the chain
    manipulation needs to be locked, not the elements' state changes.

    https://bugzilla.gnome.org/show_bug.cgi?id=741355

commit a848ac7abe0664d6aa0d7b8e6368534ac34be22b
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Wed Feb 4 11:46:09 2015 +0000

    decodebin: guard against the decode chain going while a pad is added

    https://bugzilla.gnome.org/show_bug.cgi?id=741355

commit 9036dc85940c1decb5c12ee253a6657b9cf70a2b
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Tue Feb 3 17:06:43 2015 +0000

    decodebin: possible fix for deadlock when spamming "next song"

    There was a deadlock between a thread changing decodebin/demuxer
    state from PAUSED to READY, and another thread pushing data
    when starting.

    From the stack trace at
    https://bug741355.bugzilla-attachments.gnome.org/attachment.cgi?id=292471,
    I deduce the following is happening, though I did not reproduce the
    problem so I'm not sure this patch fixes it.

    The streaming thread (thread 2 in that stack trace) takes the demuxer's
    sink pad's stream lock in gst_ogg_demux_perform_seek_pull and will
    activate a new chain. This ends up causing the expose lock being taken
    in _pad_added_cb in decodebin.

    Meanwhile, a state changed is triggered on thread 1, which takes the
    expose lock in decodebin in gst_decode_bin_change_state, then frees
    the previous chain, which ends up calling gst_pad_stop_task on the
    demuxer's task, which in turn takes the demuxer's sink pad's stream
    lock, deadlocking as both threads are now waiting for each other.

    https://bugzilla.gnome.org/show_bug.cgi?id=741355

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.