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 732661 - gl-cocoa: crash when aborting too early
gl-cocoa: crash when aborting too early
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal normal
: 1.3.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-03 01:42 UTC by Thiago Sousa Santos
Modified: 2014-07-04 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gl/cocoa: initalize NSApp asap when using gst-launch (1.09 KB, patch)
2014-07-03 08:11 UTC, Julien Isorce
committed Details | Review
gl/cocoa: initalize NSApp asap when using gst-launch (1.07 KB, application/octet-stream)
2014-07-03 08:26 UTC, Julien Isorce
  Details

Description Thiago Sousa Santos 2014-07-03 01:42:32 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:

  • #0 __pthread_kill
  • #1 pthread_kill
  • #2 abort
  • #3 abort_message
  • #4 default_terminate
  • #5 _objc_terminate
  • #6 safe_handler_caller
  • #7 std::terminate
  • #8 __cxa_throw
  • #9 objc_exception_throw
  • #10 -[NSException raise]
  • #11 -[NSWindow _commonAwake]
  • #12 -[NSWindow _commonInitFrame:styleMask:backing:defer:]
  • #13 -[NSWindow _initContent:styleMask:backing:defer:contentView:]
  • #14 -[NSWindow initWithContentRect:styleMask:backing:defer:]
  • #15 -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
  • #16 -[GstGLNSWindow initWithContentRect:styleMask:backing:defer:screen:gstWin:]
    at gstglwindow_cocoa.m line 372
  • #17 gst_gl_window_cocoa_create_window
    at gstglwindow_cocoa.m line 135
  • #18 gst_gl_context_cocoa_create_context
    at gstglcontext_cocoa.m line 239
  • #19 gst_gl_context_create_thread
    at gstglcontext.c line 756
  • #20 g_thread_proxy
  • #21 _pthread_start
  • #22 thread_start

Comment 1 Thiago Sousa Santos 2014-07-03 01:52:31 UTC
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'
Comment 2 Julien Isorce 2014-07-03 08:11:45 UTC
Created attachment 279820 [details] [review]
gl/cocoa: initalize NSApp asap when using gst-launch
Comment 3 Julien Isorce 2014-07-03 08:26:31 UTC
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 4 Julien Isorce 2014-07-03 09:43:17 UTC
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
Comment 5 Thiago Sousa Santos 2014-07-03 14:22:12 UTC
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?
Comment 6 Julien Isorce 2014-07-03 14:50:56 UTC
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.