[Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
Hello,

I have been very happy with how my app can be compiled for 64-bit Cocoa
so far, but on Mac OS Catalina Beta it crashes. Even the most minimal
application with only two forms crashes if you try to open the second
form as a modal dialog. It happens with both Lazarus 2.0.2 and trunk.

The error description in the crash report is quite detailed but I have
no idea what needs to be done:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Cannot update for observer <NSFrontmostDocumentWindowObserver 0x7fff8ec52208> for the key path "mainWindow.representedURL" from <TCocoaApplication 0x100d089a0>, most likely because the value for the key "mainWindow" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the TCocoaApplication class.'
Performing @selector(actionButtonClick:) from sender TCocoaButton 0x100b127e0
abort() called
terminating with uncaught exception of type NSException

It happens inside the call to beginModalSessionForWindow in
TCocoaWidgetSet.StartModal.

What can be done?

Cheers,
Tobias

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
> I have been very happy with how my app can be compiled for 64-bit
Cocoa
> so far, but on Mac OS Catalina Beta it crashes. Even the most
minimal
> application with only two forms crashes if you try to open the second
> form as a modal dialog. It happens with both Lazarus 2.0.2 and trunk.

We have a fix for that. I'll make sure it's submitted to the bug tracker on
Monday.

--
Zoë Peterson
Scooter Software


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
Hello,
wow, many thanks, I would be infinitely grateful!

Cheers,
Tobias

----

On Sun, 09 Jun 2019 10:31:13 -0500
"Zoe Peterson" <[hidden email]> wrote:

> > I have been very happy with how my app can be compiled for 64-bit
> Cocoa
> > so far, but on Mac OS Catalina Beta it crashes. Even the most
> minimal
> > application with only two forms crashes if you try to open the second
> > form as a modal dialog. It happens with both Lazarus 2.0.2 and trunk.
>
> We have a fix for that. I'll make sure it's submitted to the bug tracker on
> Monday.
>
> --
> Zoë Peterson
> Scooter Software
>

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

-----------------------------------------------------------
Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763
Directors: Tobias Giesen and Claudia Giesen

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
On Sun, Jun 9, 2019 at 11:31 AM Zoe Peterson via lazarus <[hidden email]> wrote:
I'll make sure it's submitted to the bug tracker on Monday.

Follow up! :)

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In now.  Mantis 35702

On 6/10/19 3:59 PM, Dmitry Boyarintsev via lazarus wrote:
On Sun, Jun 9, 2019 at 11:31 AM Zoe Peterson via lazarus <[hidden email]> wrote:
I'll make sure it's submitted to the bug tracker on Monday.

Follow up! :)

thanks,
Dmitry



--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
On Mon, Jun 10, 2019 at 6:18 PM David Jenkins via lazarus <[hidden email]> wrote:
In now.  Mantis 35702
 
While the research seems to be quite thorough, the following statement:
"Error is caused because Cocoa currently doesn't run through base level NSApplication.run and thus appropriate ._isrunning flag is not set " 


"...Methods to Override
...
Override run if you want the app to manage the main event loop differently than it does by default. (This a critical and complex task, however, that you should only attempt with good reason.)"

If the first statement is true, then run cannot and should not be overriden at all.

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
I'd actually encourage Tobias to try the patch at #35702 and see if it fixes the problem.

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
Hello,
the fix works fine! It does make sense, and maybe Apple changed
something in Catalina and they still need to update the documentation.

The way aloop() is called now does look like a quick workaround, maybe
it is possible to find a better looking way to run it. Maybe there is a
different callback or method override where this can be called. But
since it works fine, I am quite happy already!

And it still runs on Yosemite too.

Many thanks.

Kind Regards,

Tobias Giesen
Super Flexible Software GmbH & Co. KG

----

On Mon, 10 Jun 2019 20:00:03 -0400
Dmitry Boyarintsev via lazarus <[hidden email]> wrote:

> I'd actually encourage Tobias to try the patch at #35702 and see if it
> fixes the problem.
>
> thanks,
> Dmitry

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

-----------------------------------------------------------
Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763
Directors: Tobias Giesen and Claudia Giesen

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
On Tue, Jun 11, 2019 at 5:49 AM Tobias Giesen via lazarus <[hidden email]> wrote:
the fix works fine! It does make sense, and maybe Apple changed
something in Catalina and they still need to update the documentation.

The way aloop() is called now does look like a quick workaround, maybe
it is possible to find a better looking way to run it. Maybe there is a
different callback or method override where this can be called. But
since it works fine, I am quite happy already!

I wonder if it's related to the official support of UIKit.
UIApplication doesn't suggest overriding of events handling (it only allows to "preview" an event before it has been executed by UIKit).

The patch has been applied. I left the door open for the original implementation (with run method override).

By the way, did anyone try 32-bit Carbon app (i.e. Lazarus)? :)

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
'Override run' doesn't necessarily mean replace all of it.  Inherited can be called from the override.  And I'd agree with the addendum "(This a critical and complex task, however, that you should only attempt with good reason.)". 

I looked at the assembly for NSApplication.run, there are a lot of things being called and set before the call to nextEventMatching...   The .isRunning variable being one of them - which is read only and can't be set.  It can be overridden (and is one of the suggested overrides) but unfortunately there are times, in other parts of the code, that they look directly at the ._running variable where the value of .isRunning is stored instead of calling .isRunning (look at NSApplication._setMainWindow).  Which sets up a mismatch between what an overridden .isRunning method would return and what ._running is set to.

Obviously the overrides have worked fine so far.  And I agree with Tobias that it is code changes in the 10.15 beta that has really caused this to not work.  Setting up NSFrontmostDocumentWindowObserver is new to 10.15 and that is where the fault has happened.  It is beta software and bugs will be there.  Or functionality that will be removed before release.  Nevertheless I'd suggest a couple of cautionary points with regards to overriding run:

1) I have found Apple Documentation to be overly sparse at points and that it doesn't keep up well with new code.  So reading that it you can override .run in the Documentation doesn't immediately suggest to me that it is a good idea or should be done.

2) Take the "(This a critical and complex task, however, that you should only attempt with good reason.)" seriously and call inherited or look at inherited (lldb/assembly) and try to implement most of what happens there.  Notice that the initial override of run did cause a bug in Lazarus that had to be resolved by overriding .isRunning.

I'm fine with a more elegant way to call aloop.  The advantage of what we have done is that it is the very first thing that happens when NSApplication.run calls nextEventMatching - no if ands or buts.  I had originally kicked it off by calling postEvent(event, Yes) (put event at top of queue).  This does not guarantee that nothing else happens before we get aloop running.  It would be nice to not have the to check 'isrun' each time through nextEventMatching.

David




On 6/10/19 6:56 PM, Dmitry Boyarintsev via lazarus wrote:
On Mon, Jun 10, 2019 at 6:18 PM David Jenkins via lazarus <[hidden email]> wrote:
In now.  Mantis 35702
 
While the research seems to be quite thorough, the following statement:
"Error is caused because Cocoa currently doesn't run through base level NSApplication.run and thus appropriate ._isrunning flag is not set " 


"...Methods to Override
...
Override run if you want the app to manage the main event loop differently than it does by default. (This a critical and complex task, however, that you should only attempt with good reason.)"

If the first statement is true, then run cannot and should not be overriden at all.

thanks,
Dmitry



--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
On Tue, Jun 11, 2019 at 10:06 AM David Jenkins via lazarus <[hidden email]> wrote:
I looked at the assembly for NSApplication.run, there are a lot of things being called and set before the call to nextEventMatching...   The .isRunning variable being one of them - which is read only and can't be set.  It can be overridden (and is one of the suggested overrides) but unfortunately there are times, in other parts of the code, that they look directly at the ._running variable where the value of .isRunning is stored instead of calling .isRunning (look at NSApplication._setMainWindow).  Which sets up a mismatch between what an overridden .isRunning method would return and what ._running is set to.

Let's back-up a little bit.

Can we actually try to set the value for the instance variable?
1) it's absolutely legal in Objective-C terms (object_getInstanceVariable, object_setInstanceVariable).
2) its' absolutely legal in KVC term. (I can presume that KVC is pretty much based on top of objc-run time. And this is how the entire Swift<->ObjC binding works)

Can anyone try and modify TCocoaApplication.run to look like this. (If you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE} defines in cocoadefines.inc}

procedure TCocoaApplication.run;
begin
  self.setValue_forKey(NSNumber.numberWithBool(true),NSSTR('_running')); // setting instance variable through KVC
  isrun:=true;
  aloop();
end;  

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
yes I tried 32 Bit apps on Catalina and they cannot be run


-----

Please excuse the shortness of this mail which was sent from my mobile phone. If necessary, I will send more information later.

Cheers,
Tobias Giesen

Am 11.06.2019 um 15:13 schrieb Dmitry Boyarintsev via lazarus <[hidden email]>:

On Tue, Jun 11, 2019 at 5:49 AM Tobias Giesen via lazarus <[hidden email]> wrote:
the fix works fine! It does make sense, and maybe Apple changed
something in Catalina and they still need to update the documentation.

The way aloop() is called now does look like a quick workaround, maybe
it is possible to find a better looking way to run it. Maybe there is a
different callback or method override where this can be called. But
since it works fine, I am quite happy already!

I wonder if it's related to the official support of UIKit.
UIApplication doesn't suggest overriding of events handling (it only allows to "preview" an event before it has been executed by UIKit).

The patch has been applied. I left the door open for the original implementation (with run method override).

By the way, did anyone try 32-bit Carbon app (i.e. Lazarus)? :)

thanks,
Dmitry
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
I will try it in a few hours 


-----

Please excuse the shortness of this mail which was sent from my mobile phone. If necessary, I will send more information later.

Cheers,
Tobias Giesen

Am 11.06.2019 um 16:19 schrieb Dmitry Boyarintsev via lazarus <[hidden email]>:

On Tue, Jun 11, 2019 at 10:06 AM David Jenkins via lazarus <[hidden email]> wrote:
I looked at the assembly for NSApplication.run, there are a lot of things being called and set before the call to nextEventMatching...   The .isRunning variable being one of them - which is read only and can't be set.  It can be overridden (and is one of the suggested overrides) but unfortunately there are times, in other parts of the code, that they look directly at the ._running variable where the value of .isRunning is stored instead of calling .isRunning (look at NSApplication._setMainWindow).  Which sets up a mismatch between what an overridden .isRunning method would return and what ._running is set to.

Let's back-up a little bit.

Can we actually try to set the value for the instance variable?
1) it's absolutely legal in Objective-C terms (object_getInstanceVariable, object_setInstanceVariable).
2) its' absolutely legal in KVC term. (I can presume that KVC is pretty much based on top of objc-run time. And this is how the entire Swift<->ObjC binding works)

Can anyone try and modify TCocoaApplication.run to look like this. (If you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE} defines in cocoadefines.inc}

procedure TCocoaApplication.run;
begin
  self.setValue_forKey(NSNumber.numberWithBool(true),NSSTR('_running')); // setting instance variable through KVC
  isrun:=true;
  aloop();
end;  
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
On 6/11/2019 9:19 AM, Dmitry Boyarintsev via lazarus wrote:
> Can we actually try to set the value for the instance variable?
>
> Can anyone try and modify TCocoaApplication.run to look like this. (If
> you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE}
> defines in cocoadefines.inc}

David did the research on this one, but IMHO, this is a bad idea.  As he
said, the inherited run does more than just set _running before it
starts calling nextEventMatchingMask; that's is just the bit that causes
an obvious crash.  It's also poking around the implementation rather
than relying on the public API, so it will be more likely to break again
going forward.

If it's a problem to check isRunning every time through
nextEventMatchingMask, and alternative with the same behavior would be
to swizzle in the runloop variant before calling inherited run and
switching it back once we get into it.

--
Zoë Peterson
Scooter Software

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus <[hidden email]> wrote:
David did the research on this one, but IMHO, this is a bad idea.  As he
said, the inherited run does more than just set _running before it
starts calling nextEventMatchingMask;
Yet Apple suggests that "run" method can be overridden.
That's very true, that Apple can add much more into "run" method and it would be nice if we could use the code.
Yes, overriding "run" has its own risk of not being future compatible. 
But I don't recall any flawless macOS update. On each new macOS version there were some "LCL incompatible" changes anyway.
 
that's is just the bit that causes an obvious crash.  It's also poking around the implementation rather
than relying on the public API, so it will be more likely to break again going forward.
Public API is actually refers to methods, not instance names.
Actually instance variable name are specifically should be named with underscore in them 
 
If it's a problem to check isRunning every time through
nextEventMatchingMask, and alternative with the same behavior would be
to swizzle in the runloop variant before calling inherited run and
switching it back once we get into it.
Switching back? how is it possible? 

I don't really like the idea of hijacking the event loop for quite a simple reason.
The nextEventMatchingMask can be called for whatever event, and hijacking can violate the conditions of the call.
(for example, if the method is called with a timeout, and LCL hijacks the loop. Then it never returns withing specified time).

We cannot be sure at what particular event, the hijacking would occur.
Today, there was a bug report, about crash in the hijacking approach
The application written caused nextEventMatchMask to be called even prior to Application.Init.
So eventually the method is as risky as overriding "run", and not a good design.

(for example: NSApplication might send a certain event to NSWindow. Until the event has been processed it would leave some internal variables uninitialized as well)

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
Btw, I'd prefer to keep COCOALOOPOVERRIDE define in the source code.
As neither approach is 100% clean, we'll pretty much want to have an option to switch between one another.

The cleanest way however - is to modify LCL itself! 
So there would be no need to call a "runloop" procedure (thus no need to either hijack the event loop and/or override run)
Obviously, on the condition that the widgetset CAN handle Pascal exceptions in LCL friendly manner.

thanks,
Dmitry

On Wed, Jun 12, 2019 at 12:56 AM Dmitry Boyarintsev <[hidden email]> wrote:
On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus <[hidden email]> wrote:
David did the research on this one, but IMHO, this is a bad idea.  As he
said, the inherited run does more than just set _running before it
starts calling nextEventMatchingMask;
Yet Apple suggests that "run" method can be overridden.
That's very true, that Apple can add much more into "run" method and it would be nice if we could use the code.
Yes, overriding "run" has its own risk of not being future compatible. 
But I don't recall any flawless macOS update. On each new macOS version there were some "LCL incompatible" changes anyway.
 
that's is just the bit that causes an obvious crash.  It's also poking around the implementation rather
than relying on the public API, so it will be more likely to break again going forward.
Public API is actually refers to methods, not instance names.
Actually instance variable name are specifically should be named with underscore in them 
 
If it's a problem to check isRunning every time through
nextEventMatchingMask, and alternative with the same behavior would be
to swizzle in the runloop variant before calling inherited run and
switching it back once we get into it.
Switching back? how is it possible? 

I don't really like the idea of hijacking the event loop for quite a simple reason.
The nextEventMatchingMask can be called for whatever event, and hijacking can violate the conditions of the call.
(for example, if the method is called with a timeout, and LCL hijacks the loop. Then it never returns withing specified time).

We cannot be sure at what particular event, the hijacking would occur.
Today, there was a bug report, about crash in the hijacking approach
The application written caused nextEventMatchMask to be called even prior to Application.Init.
So eventually the method is as risky as overriding "run", and not a good design.

(for example: NSApplication might send a certain event to NSWindow. Until the event has been processed it would leave some internal variables uninitialized as well)

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
Dmitry Boyarintsev via lazarus wrote:

> On Tue, Jun 11, 2019 at 10:06 AM David Jenkins via lazarus
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     I looked at the assembly for NSApplication.run, there are a lot of
>     things being called and set before the call to
>     nextEventMatching...   The .isRunning variable being one of them -
>     which is read only and can't be set.  It can be overridden (and is
>     one of the suggested overrides) but unfortunately there are times,
>     in other parts of the code, that they look directly at the ._running
>     variable where the value of .isRunning is stored instead of calling
>     .isRunning (look at NSApplication._setMainWindow).  Which sets up a
>     mismatch between what an overridden .isRunning method would return
>     and what ._running is set to.
>
>
> Let's back-up a little bit.
>
> Can we actually try to set the value for the instance variable?
> 1) it's absolutely legal in Objective-C terms
> (object_getInstanceVariable, object_setInstanceVariable).
> 2) its' absolutely legal in KVC term. (I can presume that KVC is pretty
> much based on top of objc-run time. And this is how the entire
> Swift<->ObjC binding works)

BTW, did we report this issue (of the running variable not set) to
Apple? Or is the below piece of code the way we should set it ourselves ?


> Can anyone try and modify TCocoaApplication.run to look like this. (If
> you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE}
> defines in cocoadefines.inc}
>
> procedure TCocoaApplication.run;
> begin
>    
> self.setValue_forKey(NSNumber.numberWithBool(true),NSSTR('_running'));
> // setting instance variable through KVC
>    isrun:=true;
>    aloop();
> end;


Marc


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
On Wed, Jun 12, 2019 at 5:17 AM Marc Weustink via lazarus <[hidden email]> wrote:
BTW, did we report this issue (of the running variable not set) to
Apple? Or is the below piece of code the way we should set it ourselves ?

I didn't bug report the issue to Apple. 
The code provide can be called by LCL

thanks,
Dmitry

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
On 6/11/2019 11:56 PM, Dmitry Boyarintsev via lazarus wrote:
>     If it's a problem to check isRunning every time through
>     nextEventMatchingMask, and alternative with the same behavior would be
>     to swizzle in the runloop variant before calling inherited run and
>     switching it back once we get into it.
>
> Switching back? how is it possible?

"Swizzling" is the name for replacing the Objective C method pointers
using method_exchangeImplementations.  It's not the same as overriding it.

There's a writeup of it here:

https://trinhngocthuyen.github.io/tech/method-swizzling-what-why-and-how/

So, rather than overriding nextEventMatchingMask directly, ours is
called something like runLoop_nextEventMatchingMask.
TCocoaWidgetSet.AppRun swaps the function pointers, soour version is
only called after we get to that point, and when we get into that
function, we swap them back and call the original implementation like
normal.  Our version only gets called once.

> We cannot be sure at what particular event, the hijacking would occur.
> Today, there was a bug report, about crash in the hijacking approach
> https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420 
>
> The application written caused nextEventMatchMask to be called even
> prior to Application.Init.

The above approach takes care of that, since our version is never used
until we actually swap the method pointers.  It removes the need to
maintain an "isRun" variable too.

--
Zoë Peterson
Scooter Software


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

Free Pascal - Lazarus mailing list
There is an alternate way to swizzle documented here, which the author
claims has less side effects.  I assume it would be possible to do this
variant with Objective Pascal, but for a proof of concept it shouldn't
be necessary:

https://blog.newrelic.com/engineering/right-way-to-swizzle/
--
Zoë Peterson
Scooter Software

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
12