GNOME Bugzilla – Bug 646811
baseparse: deadlock in gst_base_parse_set_index
Last modified: 2011-04-19 13:15:05 UTC
Opera is using a memindex on decodebin2 to have that be populated by matroskademux, allowing us to map bytes to time and vice versa with help from the seek index. This has exposed a deadlock in the new baseparse in gst-plugins-bad. Input: http://www.nch.com.au/acm/8kmp38.wav gst_base_parse_set_index takes the object lock and then calls gst_index_get_writer_id. The default resolver, GST_INDEX_RESOLVER_PATH, will use gst_object_get_path_string which also tries to take the object lock. Since it's a GMutex which is not recursive, it will simply deadlock. Backtrace:
+ Trace 226596
Other elements are doing the same btw, at least flvdemux. cddabasesrc is releasing the object lock before getting a writer ID but this doesn't sound safe to me, a different thread could set another index on the element at exactly that time and with bad luck the writer ID that is stored is the one from the old index.
I should also note that the documentation for gst_index_get_writer_id doesn't say that the caller mustn't old the object lock, do you want a separate bug for that?
> I should also note that the documentation for gst_index_get_writer_id doesn't > say that the caller mustn't old the object lock, do you want a separate bug for > that? Nah, I'll fix that (unless you have a patch at hand already).
commit 60bbb9c24f5b09ae4f6546b16ec64cd3484b2255 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Apr 19 13:23:19 2011 +0100 docs: add note/warning to gst_index_get_writer_id() docs about the OBJECT_LOCK https://bugzilla.gnome.org/show_bug.cgi?id=646811 commit b35d54dcd1afb11dd70356e67f4d95441be6d74d Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Apr 19 13:05:53 2011 +0100 baseparse: don't deadlock when setting external index Protect index with its own lock. gst_index_get_writer_id() may take the object lock internally (the default resolver, GST_INDEX_RESOLVER_PATH, will anyway), so if we're using that to protect the index as well, we'll deadlock. https://bugzilla.gnome.org/show_bug.cgi?id=646811