> On Nov 17, 2020, at 7:52 AM, Allin Cottrell <cottr...@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.)


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: 
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.

John Ralls

gtk-osx-users-list mailing list

Reply via email to