GNOME Bugzilla – Bug 575563
The last gstreamer sometime deadlock when it wasn't a few month ago
Last modified: 2009-12-01 16:18:12 UTC
I wrote a peace of code with gst-python and I was testing it with a gstreamer checkout of some month ago. I had some random warning saying "loop detected in the graph of bin pipeline" that append when I was removing a fakesink from an iterating pipeling going to STATE_PLAYING. To check if it was fixed, I upgraded gstreamer and deps to the last git, and now I don't have warning anymore, instead I have deadlocks... I will attached a gstreamer log with GST_DEBUG=3,*bin*:5,*STATE*:5.
Created attachment 130751 [details] Log of the deadlock
can you make a backtrace of all threads by running the app, then wait for the deadlock, attach gdb -p <pid> and then thr apply all bt.
Ping?
Sorry, I didn't sow the reply. Here are the threads backtraces:
+ Trace 214290
This is from the today last gstreamer checkout. Could it be that some queue/multiqueue behavior changed ? The version 0.10.21 (Ubuntu packages) works just fine.
It looks like some queue is filled while the other one is empty. What kind of asf file is this? can you attach it?
This is not happening reliably with some particular file, since the gstreamer update, it randomly deadlock on various files using various codecs. I'll join a file that always deadlock the program after a few runs.
Created attachment 132952 [details] A file that make the program deadlock after a few runs
It's not really a deadlock. One thread is waiting in a pad block. The main thread is simply waiting in the mainloop.
You probably need to make the multiqueue code a bit more robust in your code.