GNOME Bugzilla – Bug 758584
gstbin: deadlock on state change?
Last modified: 2015-12-01 17:13:38 UTC
Created attachment 316152 [details] gdb session demonstrating the problem In my dynamically constructed pipeline I'm seeing a deadlock as seen in the attachment. I've started seeing this problem after simplifying my pipeline slightly but otherwise it has the same logical structure apart from one bin I have removed (now uridecodebin and decodebin are wrapped in a single bin while previously these lived in separate bins). This suggests to me there's a race somewhere resulting in a deadlock. I'd appreciate if someone could have a look at the gdb dump attached. I wonder if this is a user error, new/wrong use case or a genuine problem with GstBin.
Created attachment 316233 [details] Pipeline layout The picture demonstrate the pipeline layout.
Can you use GST_DEBUG to log element and peer_element ? It's not clear whether gdb may be being confused by optimization. If those two are the same, then it'd mean an element is linked to itself, which seems unusual.
I'm not really sure what would I need to do to log element and peer_element as all what I know is that they're both the same thing. It's a valid point that this could be gdb optimising out some code and presenting confusing results. I'll try to explore that further. I've tried to hack the thing by adding a check in line 2005 against peer_element != element and deadlock goes away but I'm not sure what other side effects this would have. To me this proves that in that case element and peer_element were the same. I have no clue how I could arrive at this situation. The problem also goes away if I increase the debug level for gstbin to 4. I'll try to dig a bit more into that.
I just meant something like: GST_DEBUG ("%p %p", element, peer_element); But your peer_element != element works as well. I don't really trust what gdb says on optimized code. Looking at the code, it's not "an element linked to itself" as I first thought. It's a bin containing an element with a pad which goes "out of the bin", to an element which is inside the bin. So I *think* that the relevant pad was exposed outside the bin though it should not have been. Not sure how you'd end up with that though. Do you have code that creates/changes proxy pads etc, where one could be linked to the wrong target ?
How about the diagram I've attached? That shows how the pipeline looks like.
I think you were right, I was mirroring a src pad from uridecodebin on my outermost bin and then connecting it with the element within that bin. So it's my error. Closing the ticket.