GNOME Bugzilla – Bug 674043
[0.11] Serialized allocation query deadlocks
Last modified: 2012-04-16 11:49:28 UTC
QT Demuxer deadlocks when posting the (now serialized) allocation query Stack trace:
+ Trace 230057
gst_multi_queue_sink_query blocks until there is response for the query, but the response never comes because of a blocking probe. The blocking probe will be lifted when other streams are exposed, which doesn't happen because qtdemux loop thread is stuck. I might be missing something here but how can serialized queries work (given current implementation) with queues without deadlocking?
(In reply to comment #0) >I might be missing something here but how can serialized queries work (given >current implementation) with queues without deadlocking? It's not related to serialized events. In this case, qtdemux should first expose the pads and then do the allocation queries on them.
I didn't mention serialized events, i meant serialized queries. What if (hypothetically) there is a blocking probe that will only be removed when there is data coming on other pads. The data will never come though because qtdemux gets stuck doing the allocation query. i.e. +----+---[ Pad1: thread blocked by probe / | | lifted when there is data on other branches] QtDemux +--| MQ +---[ Pad2 ] \ | | +----+---[ Pad3 ] QtDemux will do Allocation Query on pad1 from the loop thread. The thread is paused until Pad1 responds. However there is blocking probe on pad1 that will only be lifted when some other probe (on pad2 or 3) gets data, caps event etc. Normally the probe wouldn't be a problem because there is a multiqueue. However with serialized queries the query will block the loop thread immediately, even with multiqueue.
(In reply to comment #2) > I didn't mention serialized events, i meant serialized queries. I meant serialized queries. > > What if (hypothetically) there is a blocking probe that will only be removed > when there is data coming on other pads. The data will never come though > because qtdemux gets stuck doing the allocation query. > > i.e. > > +----+---[ Pad1: thread blocked by probe > / | | lifted when there is data on other branches] > QtDemux +--| MQ +---[ Pad2 ] > \ | | > +----+---[ Pad3 ] > > QtDemux will do Allocation Query on pad1 from the loop thread. The thread is > paused until Pad1 responds. However there is blocking probe on pad1 that will > only be lifted when some other probe (on pad2 or 3) gets data, caps event etc. You should make the probe not block on the query. Then the query will be done (not-linked or you can reply yourself) and dataflow continues as it was before. The fact that the query is serialized is not a problem, the new thing is that the blocking probe and also block on queries now. I was talking about another case where the app is waiting for no-more-pads to remove the probes.
Created attachment 212131 [details] [review] decodebin should not block on caps event Decodebin blocking on caps event was blocking the demuxer loop thread
Created attachment 212135 [details] [review] decodebin should not block on sticky and oob events
Created attachment 212137 [details] [review] decodebin should not block on sticky and oob events
Created attachment 212139 [details] [review] decodebin should not block on sticky and oob events put the block after variable declarations
commit b6765417e18fd97435b77464439c999f49c6a186 Author: Matej Knopp <matej.knopp@gmail.com> Date: Mon Apr 16 13:43:41 2012 +0200 decodebin: Do not block on sticky and oob events