[Bug 755260] decodebin: Fix a race condition accessing the decode_chain field.

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from GstBlub <gstblub at gmail.com> ---
This patch effectively introduces a new state for the GstDecodeChain.  Freeing
and then actually destroying it (when the ref count hits zero).  As far as I
can tell, freeing the chain and its content is always done with the expose lock
held, it however won't actually be destroyed unless no one else (e.g. a
type_found signal scheduled to be executed) might care about it.  So if anyone
else (like type_found) may access the chain and it already got freed (but not
destroyed), it can still lock the chain's mutex and check if it was freed.

The reason I'm adding a ref in the quoted hunk is that because I need to unlock
the expose lock prior to calling into analyze_new_pad().  Because it needs to
be unlocked, a state change could happen that would otherwise free and destroy
the decode_chain.  Because it keeps an additional reference prior to calling
into analyze_new_pad(), a state change allows the decode_chain to be freed, but
it won't actually be destroyed (meaning the chain's mutex is still usable)
until both analyze_new_pad() and the state change handler no longer need the
GstDecodeChain.  Within analyze_new_pad() access to the chain doesn't really
need the expose lock, it only needs the chain's lock itself.  The expose lock
really only should be necessary when accessing the decode_chain member, which
means if any code needs to use the debug chain and unlock the expose chain, it
should be ref'ed and when it no longer is needed it should be unref'ed.

I hope this makes sense.

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