GNOME Bugzilla – Bug 343278
g_object_notify() not threadsafe (and also all callers)
Last modified: 2008-05-06 12:50:54 UTC
Several GStreamer core functions supposed to be MT safe call g_object_notify() without holding a lock on the object. This allows a race condition in g_object_notify_queue_thaw(), if another thread adds a notification while the notification queue is processed. In that case, g_object_notify_queue_thaw() tries to store too much data into a preallocated array. This results in a segfault. The attached patch moves the g_object_notify() calls to the locked section, and modifies gst_object_dispatch_properties_changed() so it does not attempt to lock the object to avoid the deadlock. After applying these changes, we encountered neither the segfault, nor a deadlock so far.
Created attachment 66405 [details] [review] race condition fix
what glib version are you using, this is supposed to be solved in glib. Also we don't want to take the object lock while emiting the notify as it can create all sorts of nasty deadlocks.
We use glib 2.10.2. AFAICS this is still an issue with CVS glib. the problem is in this sequence in gobject.c:g_object_notify : g_object_notify_queue_add (object, nqueue, pspec); g_object_notify_queue_thaw (object, nqueue); When one thread calls queue_add while other one executes queue_thaw, the program crashes. The freeze/add/thaw sequence would need some locking to be safe.
holding the object lock while emiting the notify is not acceptable. I never saw a crash with notify, although I understand there is a theoretical problem. Can you provide a testcase so that we can verify any solution? I remember we had a class wide lock for this stuff in the gst_object_dispatch_properties_changed() function. It would be nice to see if readding that lock would solve the issue as well. it was removed in the following patch: http://webcvs.freedesktop.org/gstreamer/gstreamer/gst/gstobject.c?r1=1.113&r2=1.114
Jindrich, can you try the change Wim asked in comment #4?
As far as I can remember, the code the patch refers to was still in the GStreamer release we used. Anyway, a few weeks after this report, we refrained from using GStreamer in this particular application due to performance and stability issues we were unable to resolve.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!