GNOME Bugzilla – Bug 585970
gst_audioringbuffer_get_type is not thread safe
Last modified: 2009-06-16 13:53:00 UTC
Many _get_type functions in gstreamer (core and plugins) aren't thread safe, but this particular one I've been getting asserts on when starting several pipelines in parallel. The fix is simple, patch attached, but perhaps a larger bug to fix all of these should be opened.
Created attachment 136713 [details] [review] use G_DEFINE_TYPE
I fixed this yesterday actually: commit 3767cb60053eb12d346c815fbe695a1d2ec265b0 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Mon Jun 15 15:39:09 2009 +0100 audiosink,audiosrc: ref the audio ring buffer class and type in class_init Hack around thread-safety issues in GObject and our racy _get_type() functions (we could easily fix the _get_type() functions, but we still need to hack around the GObject class races until we require a newer GLib version, I think). If you find other cases, or want to do a general code review, please open separate bugs for those, thanks!
Perhaps I'm missing something, but your fix yesterday looks very circular. gst_audioringbuffer_get_type has a race condition, but gst_audioringbuffer_class_init would only be called after gst_audioringbuffer_get_type (as it is declared static and only referenced in _get_type). How then does g_type_class_ref (GST_TYPE_AUDIORING_BUFFER) in gst_audioringbuffer_class_init help matters? Debugging confirms that the order of calls is _get_type and then _class_init.
Err, you're absolutely right of course (oops!). These refs were supposed to go into the other class_init functions :) Thanks for noticing. Let's try this then: commit 70089160f84d882d1ee7cd1708df1ee87bf69b08 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Jun 16 14:05:04 2009 +0100 audiosink, audiosrc: do the class_ref()s in the right class_init functions Spotted by Philip Jägenstedt. Hopefully fixes #585970 for real. (Btw, your patch would've been fine as well I guess, although it seems that it would have needed at least a typedef and the same fix for the source, so we end up with different GType names for the audio ring buffers in the source and the sink.)
OK, since GstAudioSink uses the boilerplate macro I guess this should be safe. Thanks for fixing!