[Bug 755329] Race condition around finish_unprepare

[GStreamer (GNOME Bugzilla)]

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

Jake Foytik <jake.foytik at ipconfigure.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jake.foytik at ipconfigure.com

--- Comment #1 from Jake Foytik <jake.foytik at ipconfigure.com> ---
I am seeing a race condition in the finish_unprepare() function too. I am able
to easily reproduce the issue by having multiple clients simultaneously
disconnect from my server. Occasionally, this will result in two threads
simultaneously entering the finish_unprepare() function, which results in one
thread removing priv->rtpbin from the bin and setting it to NULL and the next
process will then get errors on the bin_remove.

I think the problem stems from the unlock/lock that happens within
finish_unprepare() :
  /* release the lock on shutdown, otherwise pad_added_cb might try to
   * acquire the lock and then we deadlock */
  g_rec_mutex_unlock (&priv->state_lock);
  set_state (media, GST_STATE_NULL);
  g_rec_mutex_lock (&priv->state_lock);

By unlocking, this gives other threads the ability to progress into the
finish_unprepare function as well.

We could either revise the locking strategy, or add a check after the
finish_unprepare acquires the the lock on priv->state_lock that could then
short-circuit the remainder of the function.

As a quick fix, I've added added a check for the UNPREPARED state right after
the g_rec_mutex_lock. Seems to have helped, but I am unsure if it will have any
unintended consequences.

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