GNOME Bugzilla – Bug 789143
Occasional deadlock in gst_element_set_state
Last modified: 2018-01-25 07:39:30 UTC
Created attachment 361799 [details] full backtrace of all threads In a 1.8.3 based installation we see occasional deadlocks during shutdown of our playback pipe in gst_element_set_state. Occasional means: on >1k installations <10 times a day. And seems it happens only on certain streams (720p live IP-TV streams with occasional network hickups). That means we can't reliably reproduce. I know this is 1.8.x and pretty old, but prior to upgrading to 1.12 we'd like to figure out if we can expect this to be fixed in 1.12 or if we have to further dig. Full backtrace attached. Seems like this is an issue between Thread 31 and Thread 1. Therefore tentatively assigned to component gstreamer-vaapi. We checked git log 1.8.3..1.12.3 of gstreamer-vaapi (and gstpad.c) and did at a first look not find anything related. Would help if you could have a quick look at the bt and tell whether there is an obvious problem and in which direction we should continue. Thanks!
Created attachment 362384 [details] Full backtrace with 1.12.3 Seems to deadlock on 1.12.3 too
as far as I read, the problem relies on the fact that the vaapi decoder only has a limited number of output buffers, and it waits until they return back to the pool in order to provide more. I don't know you code, but it looks to me like if you are holding those buffers. A workaround would be to place a vaapipostproc right after the decoder, so the postprocessor could create any number of output buffers, limited only by the memory (gpu or cpu depending on the backend).
This was seen in a pretty basic playbin-based application. We definitely don't ref any buffers. Because this happens so rarely and we implemented a workaround already I fear we can't provide any more input for this case.