GNOME Bugzilla – Bug 732661
gl-cocoa: crash when aborting too early
Last modified: 2014-07-04 12:57:34 UTC
if I use playbin to play some video with gst-launch-1.0 and interrupt it right at the beginning I might get the following crasher:
+ Trace 233760
If this helps this message is printed: 2014-07-02 21:26:55.447 gst-launch-1.0[31772:8d1f] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating CGSWindow on line 259'
Created attachment 279820 [details] [review] gl/cocoa: initalize NSApp asap when using gst-launch
Created attachment 279821 [details] gl/cocoa: initalize NSApp asap when using gst-launch Even with G_PRIORITY_DEFAULT_IDLE it seems to be faster than g_timeout_add(0,..) which is G_PRIORITY_DEFAULT. I wonder if this is due to the interval, even if this is 0 here. See https://git.gnome.org/browse/glib/tree/glib/gmain.c?h=glib-2-40 the ready_time should
Comment on attachment 279820 [details] [review] gl/cocoa: initalize NSApp asap when using gst-launch commit 6e51790a11835490fa037bdaf996ffd316e74fb1 Author: Julien Isorce <julien.isorce@gmail.com> Date: Thu Jul 3 09:00:32 2014 +0100 glcocoa: initalize NSApp asap when using gst-launch See https://bugzilla.gnome.org/show_bug.cgi?id=732661
How does changing g_idle_add and g_timeout make it be executed for sure? I'm missing something here. Doesn't this only reduce the risks?
I could keep g_timeout_add_full (interval=0). The important thing here is the priority. And yes it just reduces the risk. Another solution would be to not call it from "gst_gl_context_cocoa_class_init" but doing it inside gst_gl_context_cocoa_new using a g_once_init_enter/leave. And return NULL if NSApp init fails instead of a warning. Indeed the crashed you got happened because ctrl-c trigger to skip the g_timeout/idle callback which init the NSApp. But no matter the result it still tried to create the NSWindow.