Back in 2106 there was a thread concerning a crash on macOS when (a)
a GTK window is maximized, then (b) the user tries to close the
maximized window via the quartz control button ("x"). See
https://mail.gnome.org/archives/gtk-osx-users-list/2016-February/msg00005.html
and following.
I thought we were done with that; there seemed to be fix in hand and
no more was heard of the problem. But now I'm seeing the same thing
again -- this is with GTK 2.24.32 on macOS 10.15.7. The crash report
from the OS looks just like before, with the coup de grace in this
sequence:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libgdk-quartz-2.0.0.dylib 0x000000010bb690a5 -[GdkQuartzView
updateTrackingRect] + 37
1 libgdk-quartz-2.0.0.dylib 0x000000010bb69249 -[GdkQuartzView setFrame:] + 105
2 com.apple.AppKit 0x00007fff2d5d889b -[NSThemeFrame setStyleMask:] +
1008
Any ideas on what might have changed to allow this bug to re-emerge?
Just for reference, here's the code for the function at issue, in
GdkQuartzView.c. In 2016 the problem was handled by checking for
"!impl" as well as "!impl->toplevel" before doing anything
substantive. Now apparently that is not sufficient.
-(void)updateTrackingRect
{
GdkWindowObject *private = GDK_WINDOW_OBJECT (gdk_window);
GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (private->impl);
NSRect rect;
if (!impl || !impl->toplevel)
return;
if (trackingRect)
{
[self removeTrackingRect: trackingRect];
trackingRect = 0;
}
if (!impl->toplevel)
return;
/* Note, if we want to set assumeInside we can use:
* NSPointInRect ([[self window] convertScreenToBase:[NSEvent
mouseLocation]], rect)
*/
rect = [self bounds];
trackingRect = [self addTrackingRect: rect
owner: self
userData: nil
assumeInside: NO];
}
--
Allin Cottrell
Department of Economics
Wake Forest University
_______________________________________________
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
