GNOME Bugzilla – Bug 575406
[collectpads] Race condition if collected function returns an error
Last modified: 2009-03-22 15:50:31 UTC
Hi, there's a race condition in collectpads. If the collected function returns an error, i.e. not GST_FLOW_OK, this will be forwarded upstream. Now upstream probably will post an error message on the bus and sends EOS downstream. If this error message is not handled yet and the pipeline stopped, collectpads will call the collected function again for the EOS for all remaining buffers on some pads. This is absolutely unexpected and will most probably result in weird errors inside the element that uses collectpads (like mine). This is of course less likely to happen if the element that uses collectpads posts an error message on the bus before returning a non-GST_FLOW_OK flowreturn but it can still happen. Solution would be to set collectpads into an error state and not call the collected function again. I'll make a patch later... Any comments on this?
Created attachment 130698 [details] [review] collectpads.diff Possible patch... this works for my case at least.
I'm curious as to how receiving EOS on one of the collectpads is labeled as 'absolutely unexpected' in your use case.
Well, receiving EOS is not what is unexpected... that's fine. The problem in my case is, that there is no way to detect if we have EOS without errors before, if we are running and don't have EOS or if we have EOS and had an error before. In case of error I don't think we want to call the collected function again as we already know that everything is broken. Also the element can't know this and if it's called again it will do whatever it should do as if nothing has happened. This can be quite unexpected IMHO ;)
We should try to push the EOS downstream somehow (even in error) when all the pads are EOS and that is usually done by calling the collect function which checks for NULL in the collectpads. So what exactly the use case that is failing here?
The problem here is the check for NULL. There might still be buffers queued up for some pads
Ok, after some more thinking about this bug I'll close it as INVALID because the behaviour actually makes sense.