After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768514 - queue: ensure all threads waiting for qlock are woken on query done
queue: ensure all threads waiting for qlock are woken on query done
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-07 11:23 UTC by Vincent Penquerc'h
Modified: 2016-07-07 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
queue: ensure all threads waiting for qlock are woken on query done (1.04 KB, patch)
2016-07-07 11:24 UTC, Vincent Penquerc'h 		rejected Details | Review

Description Vincent Penquerc'h 2016-07-07 11:23:48 UTC 
The test case for this is sending a drain query, that patch is a bit of a hack, but I can post it if requested. The use of _signal would cause a lockup from time to time as the right thread wasn't being unblocked.
Comment 1 Vincent Penquerc'h 2016-07-07 11:24:22 UTC 
Created attachment 330991 [details] [review]
queue: ensure all threads waiting for qlock are woken on query done
Comment 2 Sebastian Dröge (slomo) 2016-07-07 11:34:38 UTC 
Comment on attachment 330991 [details] [review]
queue: ensure all threads waiting for qlock are woken on query done

Seems correct but: how can you end up with two threads being blocked on that condition variable at the same time? That seems like a bug elsewhere too if I'm not missing anything.
Comment 3 Vincent Penquerc'h 2016-07-07 11:44:05 UTC 
That's a fair point, there seems to be only one place a wait can happen, and it's locked by qlock. I'll see if I can find anything else.
Comment 4 Vincent Penquerc'h 2016-07-07 14:44:12 UTC 
I can't seem to be able to reproduce the original hang now...
Comment 5 Sebastian Dröge (slomo) 2016-07-07 15:05:43 UTC 
Let's close this then? :)
Comment 6 Vincent Penquerc'h 2016-07-07 15:17:01 UTC 
Alright, I'll reopen if I see anything again.