On Thu, 18 Feb 2016, John Ralls wrote:
On Feb 18, 2016, at 8:24 AM, Allin Cottrell <cottrell wfu edu> wrote: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? [...]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.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.
Some progress to report. Based on John's information I added this function to GdkQuartzWindow.c:
- (void)windowWillClose:(NSNotification*)notification
{
// Clears the delegate when window is going to be closed; since EL
// Capitan it is possible that the methods of delegate would get
// called after the window has been closed.
[self setDelegate:nil];
}
This was not itself sufficient to avert a crash when closing a
maximized GTK window on El Capitan, but it turned out it was
necessary. The other component became apparent when I stuck some
NSLog statements into GdkQuartzView.c. After a window close from
fullscreen, the function updateTrackingRect was proceeding with
a NULL value of "impl", as in
GdkWindowImplQuartz *impl =
GDK_WINDOW_IMPL_QUARTZ (private->impl);
The fix was then to replace the "don't-go-ahead" check
if (!impl->toplevel)
(which provoked the crash) with
if (!impl || !impl->toplevel)
With these two changes I'm not seeing any problems. I'm attaching a
patch against GTK 2.24.29.
BTW, I think I mistitled this thread: it seems that it was close on maximized that was the real problem rather than maximize/unmaximize. The confusing thing is that on El Capitan, maximize produces a truly "fullscreen" view, with no window controls shown, and to close the window you have to mouse up to the top of screen to reveal the window controls (and menu bar), hence generating a resize signal.
For refence, here's the relevant portion of my debugging output, following a click on close: gretl[40729] calling: -[GdkQuartzWindow windowShouldClose:] gretl[40729] created event gretl[40729] returning gretl[40729] calling: -[GdkQuartzWindow windowWillClose:] gretl[40729] self: <GdkQuartzWindow: 0x109f15870> gretl[40729] calling: -[GdkQuartzView setFrame:] gretl[40729] self: <GdkQuartzView: 0x109f180c0> gretl[40729] calling: -[GdkQuartzView updateTrackingRect] gretl[40729] private = 0x10286bd80 gretl[40729] impl = 0x0 Allin Cottrell
Attachment:
el_capitan.diff
Description: Text document