After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752379 - gl: deadlock when destroying GstGLContext from within a windows event callback
gl: deadlock when destroying GstGLContext from within a windows event callback
Status: RESOLVED DUPLICATE of bug 766533
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-14 15:47 UTC by Xavier Claessens
Modified: 2016-09-29 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Xavier Claessens 2015-07-14 15:47:27 UTC 
I'm writing an application on windows, it uses glimagesink inside a WinForm. That window has a stop button, when clicked I set pipeline to NULL state. Doing that means that from within a window event callback, the GstGLContext is finalized and blocks until the glcontext thread returns. This leads to DestroyWindow() call to destroy the internal window on which glimagesink is drawing video frames. That DestroyWindow() call never returns, because the thread handling window event is still blocked in gst_gl_context_finalize().

To workaround this issue, I had to spawn a new thread in the callback of the stop button, and set pipeline to NULL in that thread instead.

I don't know what would be a proper fix.
Comment 1 Matthew Waters (ystreet00) 2015-07-15 11:17:00 UTC 
There isn't really much one can do in this situation.  While all our function/thread handling is entirely reentrant that doesn't mean that the winsys specific code is especially when dealing with operations requiring a round trip through the window's message loop.

This will also result in different behaviour when the extra GL thread is moved out of glwindow/glcontext.
Comment 2 Xavier Claessens 2015-07-15 13:47:14 UTC 
I quickly checked the d3dvideosink code and it seems the window there creates its own thread to handle messages. I'm wondering if it's suffering from the same bug or not, will test.

It seems pretty obvious for a stop button to set pipeline to NULL, that's the most common use-case, so we should try harder to make it work. Everybody is going to fall in that trap otherwise, IMO.

Note that I'm far from a win32 expert, so it's possible my analysis of the problem is wrong. All I know is that my app (sadly proprietary, I'll try to make simple test case) hang in DestroyWindow when I set pipeline to NULL in the mouse click callback.
Comment 3 Matthew Waters (ystreet00) 2016-09-29 02:23:53 UTC 
This may be fixed by bug 766533.
Comment 4 Xavier Claessens 2016-09-29 13:29:43 UTC 
It's a dup indeed, the other bug has a workaround that got merged. I'm still unsure it's the proper fix though...

*** This bug has been marked as a duplicate of bug 766533 ***