GNOME Bugzilla – Bug 693224
appsrc deadlocks when setting pad caps before pushing buffer
Last modified: 2013-02-06 09:15:03 UTC
There's a deadlock that sometimes happens caused by gst_app_src_create leaving priv->mutex locked while executing gst_app_src_caps_negotiate, which in turn end up calling functions that ultimately lock the appsrc object. This processing happens in "appsrc:src" thread. The backtrace for this thread is:
So in the end one thread keeps waiting for the other, and vice-versa.
bugzilla reformatted my description, leaving out some information I wrote.
There's two backtraces there... the first is the one I'm referring to in my first paragraph.
The second one is for the thread that calls gst_app_src_set_caps. This function locks appsrc mutex *then* locks priv->mutex. Since this is the reverse order of locking of these mutexes in the other thread, one thread end up waiting for the other, and vice versa, leading to a deadlock.
Here's another place where priv->mutex is being locked *before* appsrc's mutex, leading to a deadlock because another thread is locking these mutexes in the reverse other:
priv->mutex is being locked here:
then appsrc's mutex is being locked here:
Author: Wim Taymans <firstname.lastname@example.org>
Date: Wed Feb 6 10:00:27 2013 +0100
appsrc: always take mutex before object lock
The locking order is to first take the appsrc mutex and then the