GNOME Bugzilla – Bug 760559
glvideomixer ! glimagesink deadlocks on resize
Last modified: 2016-02-16 23:37:37 UTC
glvideomixer ! glimagesink will deadlock rather quickly when attempting to resize the glimagesink window. obligatory backtrace: ^C Program received signal SIGINT, Interrupt. 0x00007ffff673918d in poll () from /usr/lib/libc.so.6 (gdb) t a a bt
+ Trace 235895
Thread 6 (Thread 0x7fffdffff700 (LWP 23533))
Thread 5 (Thread 0x7fffec9c3700 (LWP 23532))
Thread 4 (Thread 0x7fffed1c4700 (LWP 23531))
Thread 3 (Thread 0x7fffefb05700 (LWP 23526))
Created attachment 318929 [details] [review] glimagesink: don't push a reconfigure event from the GL thread This removes the gst_pad_push_event() from the GL thread which prevents the deadlock.
Review of attachment 318929 [details] [review]: Seems fair. Note that glvideomixer is probably wrong too as normally one should not handle the reconfigure event, but instead let the default handler mark the pad. It then should read the reconfigure flag from the streaming thread. There would be not way to link those context together, hence it would not be important which thread sends that upstream event. (it would deadlock all over gstreamer if it was not done this way everywhere else)
Btw, make sure high resolution composition meta still work afterward please (even if I believe this change should be armless).
glmixer seems to have a deficiency in this area. The deadlock is between glmixer's object lock and the GL thread submission. The object lock is needed to be able to iterate over the sink pads and retrieve the texture id's.
Created attachment 318937 [details] [review] glmixer: don't hold the object lock while calling into GL This unfortunately is not enough as videoaggregator holds the object lock while it attempts to unref some buffers in fill_queues() which will deadlock in the same way.
Created attachment 318938 [details] [review] glmixer: don't hold the object lock while calling into GL This still isn't enough.
What's the remaining problem after these two patches?
The two patches are two options. 1. Don't send the reconfigure event from the GL thread. 2. Change glvideomixer et al to not gst_buffer_unref with the object lock held. Ideally 1 shouldn't need to be performed however currently there are still some occurrences of 2 in videoaggregator et al that would need to be changed to make it work correctly.
Well, 2) I'd say then. glvideomixer should not do anything meaningful when receiving the RECONFIGURE event, it should just remember it and then do somethnig next time from its streaming thread.
It doesn't do anything special on reconfigure. It's the pad event forwarding the reconfigure event (which takes a GstIterator and attempts to lock the object lock for access to the sink pads) deadlocking with the GL thread submission as in the backtrace above.
This is some of the second solution. commit 0d94c9ae7f7dbb25285f80852dab0524dc50fa87 Author: Matthew Waters <matthew@centricular.com> Date: Wed Jan 13 14:41:22 2016 +1100 glmixer: don't hold the object lock while calling into GL Doing so can deadlock between the GL thread and the object lock e.g. when performing reconfigure events in glimagesink on a resize event. https://bugzilla.gnome.org/show_bug.cgi?id=760559
And this is the first solution that is complete. commit ccc17ebe104d009ca9fe66bb59609ec1afa372d5 Author: Matthew Waters <matthew@centricular.com> Date: Wed Jan 13 13:17:56 2016 +1100 glimagesink: don't push a reconfigure event from the GL thread Doing so may cause deadlocks when other elements attempt destroy or created GL resources. https://bugzilla.gnome.org/show_bug.cgi?id=760559