Re: [gtk-osx-users] crash on maximize/unmaximize

On Thu, 18 Feb 2016, John Ralls wrote:

On Feb 18, 2016, at 8:24 AM, Allin Cottrell <cottrell wfu edu> wrote:

On Fri, 12 Feb 2016, Miroslav Rajcic wrote:

This [see report below] sounds similar to the crashes reported to me by users of my app (I reported this case 
on this list in January) where crashes happen only on El Capitan and are related to using app in full screen 
or new split view.

It seems that El Capitan version changed something internally, because searching on the net finds many 
similar issues.

For example Atom editor crashes:

I know Atom is not a GTK+ app, but I believe that the crashes are related.
The fix for these particular crashes in Atom are explained here:

Quote: "Since EL Capitan it is possible that the methods of delegate would get called after the window has been 

Could something like this be a case for GTK+ code too?

Thanks, this sounds very plausible; it fits the facts that I have observed. My first resort here will be to 
try to implement in GdkQuartzWindow.c the fix that the Atom guys came up with. That is, add a callback for 
the windowWillClose signal that detaches the delegate.

I'm totally unfamiliar with Objective C and Apple APIs, but from looking at the Atom and GdkQuartz code it 
seems that the callback should look like this:

- (void)windowWillClose:(NSNotification*)notification
 NSWindow *nsw = get_the_window();

 [nsw setDelegate:nil];

So my question is, what should the notional call "get_the_window()" actually look like? I see in 
GdkQuartzWindow.c code to get the relevant GdkWindow in this sort of notification context, namely

GdkWindow *window = [[self contentView] gdkWindow];

and I also see in gdkwindow-quartz.c a function

gdk_quartz_window_get_nswindow(GdkWindow *window);

I guess one could chain these, but I suspect this would be more roundabout than need be. Is "self" already 
the relevant NSWindow, by any chance, or is there a more direct way of getting it?

The GtkQuartzNSWindow is its own delegate, so [self setDelegate:nil] will do the job. It's probably the right thing to do, too: If NSWindow's destructor releases the delegate and then whatever's calling it releases the NSWindow that would be a double-free.

Thanks, John, that's good to know.

That's not going to do anything for exiting fullscreen, though. The problem shown by your crash report seems to be that the GdkQuartzView's GdkWindow* member has gotten a bogus value and the crash is from trying to dereference it.

Oof, yes, you're right. In my messing around it seemed that the most reliable way to crash the application was to close a window when in fullscreen, but if just exiting fullscreen without closing can also result in a crash that won't be covered by the above.

Allin Cottrell

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]