GNOME Bugzilla – Bug 782379
glimagesink: macOS crash when used with autovideosink
Last modified: 2017-07-16 03:01:20 UTC
Created attachment 351425 [details] 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.
For the record, it works fine on Linux, and is valgrind clean. wxWidgets 2.8.12 though.
As someone reported on the mailing list: https://lists.freedesktop.org/archives/gstreamer-devel/2017-May/063891.html This can be reproduced by a simple gat-launch-1.0 command: gst-launch-1.0 videotestsrc ! autovideosink
This issue is still present in 1.12.1. working: gst-launch-1.0 videotestsrc ! glimagesink crashing: gst-launch-1.0 videotestsrc ! autovideosink Maybe of interest. When running with the glimagesink directly I get a warning message when shutting down the pipeline: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces, or set CA_ASSERT_MAIN_THREAD_TRANSACTIONS=1 to abort when an implicit transaction isn't created on a main thread. However the crashing case does not reach that point as far as I can tell.
commit 24e3cbf13bcc91fee3a88f7d7e70308256954fb2 Author: Matthew Waters <matthew@centricular.com> Date: Sun Jul 16 01:17:04 2017 +1000 gl/cocoa: keep refs over async operations Avoids dereferencing dead objects What happens in the autovideosink case is that context 1 is created and destroyed before all the async operations hae executed on the associated window. When the delayed operations execute, they then reference dead objects and crash. We fix this by keeping refs over all async operations so the object cannot be deleted while async operations are in flight. https://bugzilla.gnome.org/show_bug.cgi?id=782379 and 1.12 546092597c262d64f76164823aa0ad5585267f1e