Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
- From: Emmanuele Bassi <ebassi gmail com>
- To: John Ralls <jralls ceridwen us>
- Cc: Allin Cottrell <cottrell wfu edu>, gtk-osx-users-list gnome org
- Subject: Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
- Date: Mon, 16 Nov 2020 23:23:40 +0000
GTK 2.24 is getting one final release once GTK 4.0 is out, and after that it will be "archived"—i.e. no more releases. Additionally, it's likely we're going to close all remaining *GTK2-only* issues as "wontfix".
If you have *fixes* for issues, please: open a merge request:
Nobody working on GTK is currently spending any time fixing issues on the gtk-2-24 branch, so code contributions are most welcome.
Ciao,
Emmanuele.
> On Nov 16, 2020, at 1:46 PM, Allin Cottrell via gtk-osx-users-list <gtk-osx-users-list gnome org> wrote:
>
> 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];
> }
It's probably a use-after-free where private->impl has been freed but not NULLed. Address sanitizer is the fastest way to track down problems like that. I haven't been working much with Gtk2 in the last couple of years but The GIMP still does. Unfortunately I don't think any of them subscribe here so I suggest you open an issue at https://gitlab.gnome.org/GNOME/gtk.
Regards,
John Ralls
_______________________________________________
gtk-osx-users-list mailing list
gtk-osx-users-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
--
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]