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

2020-11-22 Thread Allin Cottrell via gtk-osx-users-list

On Thu, 19 Nov 2020, John Ralls wrote:


On Nov 19, 2020, at 1:41 PM, Allin Cottrell  wrote:

On Tue, 17 Nov 2020, John Ralls wrote:


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.


Thanks, I see now: it's GdkQuartzWindow.c in Gtk2 and GdkQuartzNSWindow.c in 
Gtk3. Looks like there are several updates for recent macOS in the latter, and 
backporting such changes to Gtk2 might be useful for retrogrades such as myself.

One question. There's a trope that appears in several places in the Gtk2 
version:

 GdkWindow *window = [[self contentView] gdkWindow];
 GdkWindowObject *private = (GdkWindowObject *)window;
 GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (private->impl);

while in the Gtk3 version, in the corresponding places, we find:

 GdkWindow *window = [[self contentView] gdkWindow];
 GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (window->impl);

Is this difference cosmetic, or is the intervening cast from *gdkWindow to 
*GdkWindowObject really required in the Gtk2 case?


It's required in Gtk2 because there GdkWindow is a typedef of struct 
_GdkDrawable, which contains only an instance of its parent class--in the case 
of GdkWindow that would be a GdkWindowObject. Without it the compiler would 
look at struct _GdkDrawable for a member impl and fail to find it; with the 
cast it looks in struct _GtkWindowObject instead where it does find it.

That indirection was removed from Gtk3 so no more cast. There are lots of other 
changes in Gtk3, particularly in the last couple of years as the architecture 
changed to ease migration to Gtk4. Quartz hasn't kept up with all of it but 
you'll still need to spend significant time learning the internals and 
differences to successfully backport.


Thanks for the clear explanation, John.

Allin Cottrell
___
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

2020-11-19 Thread John Ralls



> On Nov 19, 2020, at 1:41 PM, Allin Cottrell  wrote:
> 
> On Tue, 17 Nov 2020, John Ralls wrote:
> 
>>> 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.
> 
> Thanks, I see now: it's GdkQuartzWindow.c in Gtk2 and GdkQuartzNSWindow.c in 
> Gtk3. Looks like there are several updates for recent macOS in the latter, 
> and backporting such changes to Gtk2 might be useful for retrogrades such as 
> myself.
> 
> One question. There's a trope that appears in several places in the Gtk2 
> version:
> 
>  GdkWindow *window = [[self contentView] gdkWindow];
>  GdkWindowObject *private = (GdkWindowObject *)window;
>  GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (private->impl);
> 
> while in the Gtk3 version, in the corresponding places, we find:
> 
>  GdkWindow *window = [[self contentView] gdkWindow];
>  GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (window->impl);
> 
> Is this difference cosmetic, or is the intervening cast from *gdkWindow to 
> *GdkWindowObject really required in the Gtk2 case?

It's required in Gtk2 because there GdkWindow is a typedef of struct 
_GdkDrawable, which contains only an instance of its parent class--in the case 
of GdkWindow that would be a GdkWindowObject. Without it the compiler would 
look at struct _GdkDrawable for a member impl and fail to find it; with the 
cast it looks in struct _GtkWindowObject instead where it does find it.

That indirection was removed from Gtk3 so no more cast. There are lots of other 
changes in Gtk3, particularly in the last couple of years as the architecture 
changed to ease migration to Gtk4. Quartz hasn't kept up with all of it but 
you'll still need to spend significant time learning the internals and 
differences to successfully backport.

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

2020-11-19 Thread Allin Cottrell via gtk-osx-users-list

On Tue, 17 Nov 2020, John Ralls wrote:


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.


Thanks, I see now: it's GdkQuartzWindow.c in Gtk2 and 
GdkQuartzNSWindow.c in Gtk3. Looks like there are several updates 
for recent macOS in the latter, and backporting such changes to Gtk2 
might be useful for retrogrades such as myself.


One question. There's a trope that appears in several places in the 
Gtk2 version:


  GdkWindow *window = [[self contentView] gdkWindow];
  GdkWindowObject *private = (GdkWindowObject *)window;
  GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (private->impl);

while in the Gtk3 version, in the corresponding places, we find:

  GdkWindow *window = [[self contentView] gdkWindow];
  GdkWindowImplQuartz *impl = GDK_WINDOW_IMPL_QUARTZ (window->impl);

Is this difference cosmetic, or is the intervening cast from 
*gdkWindow to *GdkWindowObject really required in the Gtk2 case?


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


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

2020-11-17 Thread John Ralls



> 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

2020-11-17 Thread Allin Cottrell via gtk-osx-users-list

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

2020-11-17 Thread John Ralls



> 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

2020-11-17 Thread Allin Cottrell via gtk-osx-users-list

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


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

2020-11-16 Thread John Ralls



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