[Bug 782379] New: glimagesink: macOS crash with wxWidgets

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=782379

            Bug ID: 782379
           Summary: glimagesink: macOS crash with wxWidgets
    Classification: Platform
           Product: GStreamer
           Version: 1.12.0
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fzwoch at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 351425
  --> https://bugzilla.gnome.org/attachment.cgi?id=351425&action=edit
wxWidgets example

I experience reliable crashes in glimagesink in combination with wxWidgets
(3.1).

More specifically, it crashes when the pipeline does not use the glimagesink
directly but is selected by an auto element e.g. autovideosink or
fpsdisplaysink.

For example:

"videotestsrc ! autovideoconvert ! autovideosink" crashes, while
"videotestsrc ! autovideoconvert ! glimagesink" works okay.


[..]
0:00:00.139456000 48604 0x7fbe9f955230 INFO               GST_EVENT
gstevent.c:809:GstEvent *gst_event_new_caps(GstCaps *): creating caps event
video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240,
framerate=(fraction)30/1, multiview-mode=(string)mono,
pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive

** (<unknown>:48604): CRITICAL **: gst_gl_window_get_context: assertion
'GST_IS_GL_WINDOW (window)' failed
Segmentation fault: 11



* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x60)
  * frame #0: 0x0000000108273b52 libgstgl-1.0.0.dylib`-[GstGLCAOpenGLLayer
initWithGstGLContext:] + 178
    frame #1: 0x00000001082720fe
libgstgl-1.0.0.dylib`gst_gl_window_cocoa_create_window + 302
    frame #2: 0x00007fffba20e524
libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #3: 0x00007fffba2058fc libdispatch.dylib`_dispatch_client_callout + 8
    frame #4: 0x00007fffba212aac
libdispatch.dylib`_dispatch_main_queue_callback_4CF + 925
    frame #5: 0x00007fffa4b17c69
CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    frame #6: 0x00007fffa4ad8cbd CoreFoundation`__CFRunLoopRun + 2205
    frame #7: 0x00007fffa4ad81c4 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #8: 0x00007fffa4039ebc HIToolbox`RunCurrentEventLoopInMode + 240
    frame #9: 0x00007fffa4039cf1 HIToolbox`ReceiveNextEventCommon + 432
    frame #10: 0x00007fffa4039b26
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
    frame #11: 0x00007fffa25d4e24 AppKit`_DPSNextEvent + 1120
    frame #12: 0x00007fffa2d5085e AppKit`-[NSApplication(NSEvent)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
    frame #13: 0x00007fffa25c97ab AppKit`-[NSApplication run] + 926
    frame #14: 0x000000010080f59e
libwx_osx_cocoau_core-3.1.0.0.0.dylib`wxGUIEventLoop::OSXDoRun() + 174
    frame #15: 0x0000000100d75fd4
libwx_baseu-3.1.0.0.0.dylib`wxCFEventLoop::DoRun() + 52
    frame #16: 0x0000000100cc9ff1
libwx_baseu-3.1.0.0.0.dylib`wxEventLoopBase::Run() + 161
    frame #17: 0x0000000100c913df
libwx_baseu-3.1.0.0.0.dylib`wxAppConsoleBase::MainLoop() + 111
    frame #18: 0x00000001007a9aba
libwx_osx_cocoau_core-3.1.0.0.0.dylib`wxApp::OnRun() + 26
    frame #19: 0x0000000100cfd201 libwx_baseu-3.1.0.0.0.dylib`wxEntry(int&,
wchar_t**) + 145
    frame #20: 0x0000000100001f86 a.out`main + 38
    frame #21: 0x00007fffba23b235 libdyld.dylib`start + 1
    frame #22: 0x00007fffba23b235 libdyld.dylib`start + 1


Doing the same thing with a minimal objective-c Cocoa app works just well
though! So it seems like this is somehow connected on how the wxWidgets main
loop operates?

Attached is a minimal wxWidgets application that just opens a window (so the
application does not close itself) and a pipeline that does the above. No
VideoOverlay interface involved. Switching autovideosink with glimagesink shows
the two different behaviors.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.