summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthew Waters <matthew@centricular.com>2021-07-13 21:38:10 +1000
committerTim-Philipp Müller <tim@centricular.com>2021-07-16 14:49:37 +0100
commitce1c7b97a9624efab88b7e2f9124f76165e9c631 (patch)
treeb9b5e35d4c4bb828f87dafed6e84a6614a41cf5d
parent33a3c4f77c7b39ac89891bab9c6062c9462736f5 (diff)
downloadgstreamer-plugins-bad-ce1c7b97a9624efab88b7e2f9124f76165e9c631.tar.gz
rtmp2src: workaround a GLib race when destroying a GMainContext/GSource
https://gitlab.gnome.org/GNOME/glib/-/issues/803 Basically, if destruction of a GSource and its associated GMainContext are not synchronised, Then the GSource destruction can access freed GMainContext resources and cause a crash. This is not super common but can happen. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2416>
-rw-r--r--gst/rtmp2/gstrtmp2src.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/gst/rtmp2/gstrtmp2src.c b/gst/rtmp2/gstrtmp2src.c
index f5c356b11..da0f6cf8d 100644
--- a/gst/rtmp2/gstrtmp2src.c
+++ b/gst/rtmp2/gstrtmp2src.c
@@ -686,11 +686,14 @@ gst_rtmp2_src_create (GstBaseSrc * src, guint64 offset, guint size,
return GST_FLOW_OK;
out:
- g_mutex_unlock (&self->lock);
if (timeout) {
g_source_destroy (timeout);
g_source_unref (timeout);
}
+ /* Keep the unlock after the destruction of the timeout source to workaround
+ * https://gitlab.gnome.org/GNOME/glib/-/issues/803
+ */
+ g_mutex_unlock (&self->lock);
return ret;
}