GNOME Bugzilla – Bug 631853
[queue2] deadlock when using temp-location and dispatch-properties
Last modified: 2010-10-11 16:14:22 UTC
To reproduce this, open totem, open a network location, let it play a bit, then open another network location.
The problem is because when gst_queue2_open_temp_location_file() is called from the change_state method, the queue2_mutex_lock is taken...
and _open_temp_location_file emits g_object_notify() which, when dispatch properties is enabled, will try to get the value of that property, going through queue2's _get_property() which grabs the same mutex
Calling g_object_notify() with the same lock that is used to protect get/set_property is an interesting idea :)
In gst_queue2_src_activate_pull() the _open_temp_location_file() is called without the queue2 mutex, maybe it's ok if the mutex is taken after opening the temp file? If not, gst_queue2_src_activate_pull() has to be changed too. If the mutex is really necessary here (I don't think so, all accesses to the temp file should be protected by other mutexes already) open_temp_location() could return some boolean in an out parameter to have g_object_notify() called outside the function.
Author: Wim Taymans <firstname.lastname@example.org>
Date: Mon Oct 11 18:10:07 2010 +0200
queue2: release queue2 lock before notify
Make sure that we don't hold the lock when we notify the temp-location