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





On Nov 17, 2020, at 7:52 AM, Allin Cottrell <cottrell wfu edu> wrote:

On Mon, 16 Nov 2020, John Ralls wrote:

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. [...]

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.

John, thanks for forwarding my message to the gnome guys, but Emmanuele's response was kinda what I was 
expecting ("You're on your own with GTK 2").

However, when we fixed the previous incarnation of this bug, IIRC you also submitted a patch for GTK 3 -- 
so perhaps this mutation of the bug also affects GTK 3? That would be interesting to know.

I have one thought about taking this further. Last time around we put in a "nullify a pointer" callback for 
windowWillClose (in GdkQuartzWindow.c). I wonder if we now need a similar callback for a different event 
specification. I'll see what I can figure out.

One other point: Do you know if there's any way to disable the maximize control for an application's quartz 
window? Current macOS maps this to "Full Screen" (task bar hidden) and there's really no reason for anyone 
to run my application in that mode, so blocking or re-mapping the maximize action would be a possible 
workaround. (The
crash seems to be specific to closing a maximized window.)

Allin,

Gtk-osx is a Gnome project hosted on Gnome's Gitlab and this is a Gnome mailing list hosted on 
lists.gnome.org. No forwarding required!

Emmanuel didn't say "you're on your own", he said that time is running out and to get patches in ASAP.

There's a message in there, though: It's past time to migrate your app to Gtk3. Gtk2 might work OK in macOS 
11 (I haven't done anything more than cursory does-it-build checks) but Apple has a history of changing their 
APIs and at some point Gtk2 will stop working on some future version of macOS.

This SO suggests one way to prevent full-screen: 
https://stackoverflow.com/questions/33457029/osx-disable-fullscreen-mode-from-the-zoom-button
 
I just tested full-screening and red button closing GnuCash built yesterday with Gtk+-3.24.23 on macOS 11 and 
run with MallocScribble=1 to make sure that a use-after-free would crash. It closed cleanly, no crash. You 
might diff GtkNSWindow.c between Gtk2 and Gtk3 to see if there's something helpful there.

Regards,
John Ralls



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