GNOME Bugzilla – Bug 631853
[queue2] deadlock when using temp-location and dispatch-properties
Last modified: 2010-10-11 16:14:22 UTC
(gdb) bt
+ Trace 224097
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 => deadlock
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.
commit 62ffd66f109c5c17fa8b49a69a9a382ca5c76541 Author: Wim Taymans <wim.taymans@collabora.co.uk> 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 property, Fixes #631853