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 753003 - glimagesink: GstVideoOverlay crashes on widget resize (NSView / OS X)
glimagesink: GstVideoOverlay crashes on widget resize (NSView / OS X)
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal normal
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-07-29 08:43 UTC by Florian Zwoch
Modified: 2016-11-15 13:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

crash call stack (3.18 KB, text/plain)
2015-07-29 08:43 UTC, Florian Zwoch
cocoa sample app (1.43 KB, text/x-csrc)
2016-10-10 16:29 UTC, Florian Zwoch

Description Florian Zwoch 2015-07-29 08:43:55 UTC
Created attachment 308361 [details]
crash call stack

I'm using a playbin element from a wxWidgets application and setting the NSView where to draw via the GstVideoOverlay interface. Everything works perfectly fine, resizing the NSView, toggling fullscreen. No issues.

Then I stop and start over (that means: setting the state of the pipeline to NULL and releasing it - then building a completely new pipeline, giving in the same NSView as before).

The pipeline starts and runs just fine as before. *But* then as soon as I resize the NSView I get a crash drawing to the OpenGL canvas. See attachment, I don't have debug symbols in place here unfortunately. But maybe someone has an idea what may go wring here from the call stack (attached).

Running the code on Windows where it uses the d3d video sink it works as expected (Which does not necessarily imply that there couldn't be an oversight in wxWidgets or in my code).

Any ideas or hints are appreciated.
Comment 1 Matthew Waters (ystreet00) 2015-07-29 10:51:07 UTC
Right, so there's probably some lifetime issues in the OS X GL window system implementation that will explain this issue.
Comment 2 Florian Zwoch 2016-10-10 16:29:21 UTC
Created attachment 337341 [details]
cocoa sample app

Inspired by today's GStreamer Conference talk - this is a small Cocoa example that shows the issue. There is a loop that runs the same pipeline twice. On the first run resizing works perfectly fine. When the second run starts any resize attempts will crash.

Maybe this helps to comprehend the bug - or if it is a general application error this may help to close this report anyway. For a move of GL into base/good.. :-)

Tested with GStreamer 1.8.1 only at this time. I will trying to rerun on dates RC for 1.10 if that helps.
Comment 3 Matthew Waters (ystreet00) 2016-11-15 13:02:33 UTC
Thanks for the test case!

commit 23ec5aeb839a039f96e686a9083b793cc635a15c
Author: Matthew Waters <>
Date:   Tue Nov 15 22:56:25 2016 +1100

    glwindow/cocoa: remove our view from the parent when closing
    Otherwise, when the application reuses the same UIView, we were getting
    draw notifications on the previous view/layer's which weren't valid anymore
    and were referencing pointers that had been freed.