GNOME Bugzilla – Bug 767480
g_mutex_unlock hangs
Last modified: 2018-05-24 18:55:50 UTC
we have a plugin which has a task waiting for signal for some activity. we are using gstreamer 1.5.2 for development and glib version is 2.34.1 src_pad_task () { g_mutex_lock (mutex); if (var == TRUE) g_cond_wait (cond, mutex) g_mutex_unlock (mutex); ----- some buffer pushing code ---- return; } we signal it from various places and also during state change from paused to ready as below. case GST_STATE_CHANGE_PAUSED_TO_READY: -------- hw ioctls code ----------- g_mutex_lock (mutex); var = FALSE; g_cond_signal (cond); g_mutex_unlock (mutex); gst_pad_pause_task (srcpad); in a very rare case (1 out of 50) chnage state gets struck in gst_pad_pause_task (srcpad) because g_mutex_unlock (mutex) is hang. this looks strange that g_mutex_unlock (mutex) is hang. what are the possible reasons of g_mutex_unlock (mutex) getting hang ? BR/ Rajesh
A standalone testcase that reproduces the problem without gstreamer would be very much appreciated.
Hi Matthias, Its even difficult to reprouce this issue in our gstreamer video playback pipeline because it happens rarely. we have found a work around to our problem by putting some check in the beginning of src_pad_task () and issue was not reproducible in 500 execution of our test. This tkt is more about sharing info because it looked strange to me and therefore had a query about this... what is the possibility of g_mutex_unlock getting hang ? BR/ Rajesh
[ Setting NEEDINFO until an isolated minimal test case is provided. ]
On linux, GMutex is a thin wrapper around pthread facilities.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1172.