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 783753 - splitmux: Drop allocation queries
splitmux: Drop allocation queries
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other All
: Normal normal
: 1.12.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-13 14:42 UTC by Vivia Nikolaidou
Modified: 2017-06-17 07:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
splitmux: Drop allocation queries (1.60 KB, patch)
2017-06-13 14:42 UTC, Vivia Nikolaidou
committed Details | Review

Description Vivia Nikolaidou 2017-06-13 14:42:09 UTC
See commit message
Comment 1 Vivia Nikolaidou 2017-06-13 14:42:12 UTC
Created attachment 353695 [details] [review]
splitmux: Drop allocation queries

They can cause us to deadlock, while we're waiting for a new frame and
upstream is waiting for the allocation query to be answered before
sending a frame
Comment 2 Sebastian Dröge (slomo) 2017-06-13 15:29:54 UTC
Attachment 353695 [details] pushed as 96cd941 - splitmux: Drop allocation queries
Comment 3 Nicolas Dufresne (ndufresne) 2017-06-13 15:55:33 UTC
(In reply to Vivia Nikolaidou from comment #1)
> Created attachment 353695 [details] [review] [review]
> splitmux: Drop allocation queries
> 
> They can cause us to deadlock, while we're waiting for a new frame and
> upstream is waiting for the allocation query to be answered before
> sending a frame

This looks like just a workaround to some deadlock. Would it be possible to share the stacktrace of that deadlock. Does it match https://bugzilla.gnome.org/show_bug.cgi?id=783301 ? Or is this something else. Would be nice that we gather the understanding of what is being fixed here.
Comment 4 Sebastian Dröge (slomo) 2017-06-14 06:48:17 UTC
The problem here is that at any point in time, upstream can send an ALLOCATION (or any other serialized) query. This ends up in the queue inside splitmuxsink, which has to run empty for the query to be forwarded. However splitmuxsink has various parts in the code that wait for new buffers to be put into the queue before it proceeds, which then will wait forever (upstream waiting for allocation query, so no new buffers vs. downstream/splitmuxsink waiting for new buffers by upstream before consuming the current ones in the queue).