From c3d3cf074e4dc3f868d7d12c736be1e675cac432 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Sebastian=20Dr=C3=B6ge?= Date: Mon, 30 Jul 2018 18:51:35 +0300 Subject: [PATCH] pad: Ensure that the pad is blocked for IDLE probes if they are called from the streaming thread too IDLE probes that are directly called when being added will increase / decrease the "number of IDLE probes running" counter around the call, but when running from the streaming thread this won't happen. This has the effect that when running from a streaming thread it is possible to push serialized events or data out of the pad without problems, but otherwise it would deadlock because serialized data would wait for the IDLE probe to finish first (it is blocking after all!). With this change it will now always consistently deadlock instead of just every once in a while, which should make it obvious why this happens and prevent racy deadlocks in application code. https://bugzilla.gnome.org/show_bug.cgi?id=796895 --- gst/gstpad.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/gst/gstpad.c b/gst/gstpad.c index 3911dcf..c493468 100644 --- a/gst/gstpad.c +++ b/gst/gstpad.c @@ -3553,12 +3553,18 @@ probe_hook_marshal (GHook * hook, ProbeMarshall * data) info->id = hook->hook_id; + if ((flags & GST_PAD_PROBE_TYPE_IDLE)) + pad->priv->idle_running++; + GST_OBJECT_UNLOCK (pad); ret = callback (pad, info, hook->data); GST_OBJECT_LOCK (pad); + if ((flags & GST_PAD_PROBE_TYPE_IDLE)) + pad->priv->idle_running--; + if (original_data != NULL && info->data == NULL) { GST_DEBUG_OBJECT (pad, "data item in pad probe info was dropped"); info->type = GST_PAD_PROBE_TYPE_INVALID; -- 2.7.4