[gtk-osx-users] crash on updateTrackingRect is BAAACK

[Allin Cottrell <cottrell wfu edu>]

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