Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
> On Nov 17, 2020, at 12:53 PM, Allin Cottrell wrote: > >> 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. > > GtkNSWindow.c ? I'm not seeing a file of that name (or close) in the GTK 2 > codebase. Sorry, gdk/quartz/GdkQuartzWindow.c. 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
Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
On Tue, 17 Nov 2020, John Ralls wrote:
On Nov 17, 2020, at 7:52 AM, Allin Cottrell wrote:
On Mon, 16 Nov 2020, John Ralls wrote:
On Nov 16, 2020, at 1:46 PM, Allin Cottrell via gtk-osx-users-list
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/msg5.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 0x00010bb690a5 -[GdkQuartzView
updateTrackingRect] + 37
1 libgdk-quartz-2.0.0.dylib 0x00010bb69249 -[GdkQuartzView setFrame:] + 105
2 com.apple.AppKit 0x7fff2d5d889b -[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,
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.
Granted, but I'll cross that bridge when I come to it. GTK 2 works
fine on macOS 10.15 apart from this one issue.
This SO suggests one way to prevent full-screen:
https://stackoverflow.com/questions/33457029/osx-disable-fullscreen-mode-from-the-zoom-button
Ah, that's very helpful. I've patched gdkwindow-quartz.c,
_gdk_window_impl_new(), to add
[impl->toplevel
setCollectionBehavior:NSWindowCollectionBehaviorFullScreenAuxiliary];
for GDK_WINDOW_TOPLEVEL, GDK_WINDOW_DIALOG and GDK_WINDOW_TEMP, and
my woes are over. The max button now just does "regular"
maximization rather than full-screen and there's no crash closing a
maximized window.
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.
GtkNSWindow.c ? I'm not seeing a file of that name (or close) in the
GTK 2 codebase.
Allin
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
> On Nov 17, 2020, at 7:52 AM, Allin Cottrell wrote:
>
> On Mon, 16 Nov 2020, John Ralls wrote:
>
>>> On Nov 16, 2020, at 1:46 PM, Allin Cottrell via gtk-osx-users-list
>>> 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/msg5.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 0x00010bb690a5 -[GdkQuartzView
>>> updateTrackingRect] + 37
>>> 1 libgdk-quartz-2.0.0.dylib 0x00010bb69249 -[GdkQuartzView setFrame:] +
>>> 105
>>> 2 com.apple.AppKit 0x7fff2d5d889b -[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
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
Re: [gtk-osx-users] crash on updateTrackingRect is BAAACK
On Mon, 16 Nov 2020, John Ralls wrote:
On Nov 16, 2020, at 1:46 PM, Allin Cottrell via gtk-osx-users-list
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/msg5.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 0x00010bb690a5 -[GdkQuartzView
updateTrackingRect] + 37
1 libgdk-quartz-2.0.0.dylib 0x00010bb69249 -[GdkQuartzView setFrame:] + 105
2 com.apple.AppKit 0x7fff2d5d889b -[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 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
