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

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.

Hello,
wow, many thanks, I would be infinitely grateful!

Cheers,
Tobias

----

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

On Sun, Jun 9, 2019 at 11:31 AM Zoe Peterson via lazarus <

wrote: I'll make sure it's submitted to the bug tracker on Monday.

Follow up! :)

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190610/ee1f4cec/attachment.html>

In now.  Mantis 35702

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190610/41c33c5b/attachment.html>

On Mon, Jun 10, 2019 at 6:18 PM David Jenkins via lazarus <

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 "

contradicts Apple's documentation (
https://developer.apple.com/documentation/appkit/nsapplication?language=objc )

"...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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190610/8b9fb9c3/attachment.html>

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

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190610/1dbd7ae6/attachment-0001.html>

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

----

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

On Tue, Jun 11, 2019 at 5:49 AM Tobias Giesen via lazarus <

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). (nothing mentioned in release notes though:
https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes )

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/4740d49d/attachment.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/4cde693b/attachment.html>

On Tue, Jun 11, 2019 at 10:06 AM David Jenkins via lazarus <

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;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/bab3e1f7/attachment.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/0769dec6/attachment-0001.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/842f1ab0/attachment.html>

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.

On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus <

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.

Public API is actually refers to methods, not instance names. Actually instance variable name are specifically should be named with underscore in them
(
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html )

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 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190612/6424895c/attachment.html>

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 <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190612/b9b95e1c/attachment-0001.html>

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 ?

Marc

On Wed, Jun 12, 2019 at 5:17 AM Marc Weustink via lazarus <

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190612/1e2d42fb/attachment.html>

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

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.

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/

On Wed, Jun 12, 2019 at 11:48 AM Zoë Peterson via lazarus <

Quite an interesting technique. I'm quite confident it's being heavily used for Javascript.
(I guess it's somewhat natural for reflective languages to use it)

Though I'd consider going that low level as a last resort, rather than a permanent solution.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190612/e5991f7e/attachment.html>

Hello,
I found that the code must be corrected like this to avoid an Access Violation if an event occurs before the aloop field is set.

  if Assigned(aloop) and not isrun then begin
     isrun:=true;
     Result:=nil;
     aloop();
     terminate(nil);
     exit;
     end;

Kind Regards,

Tobias Giesen
Super Flexible Software GmbH & Co. KG

----

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

thanks, but it's already in the trunk

On Thursday, June 13, 2019, Tobias Giesen via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190613/b3eb750c/attachment.html>

There's one more thing about not overriding run method. The event loop needs to be "terminated" and/or "stopped" in order for run method to return.
If it doesn't return, Pascal unit finalization section won't run, and that's not good.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190614/2cde465e/attachment.html>

On Fri, Jun 14, 2019 at 9:16 AM Dmitry Boyarintsev <

A couple of things... I've modified the original patch changing terminate(nil) to stop(nil).
That should take care of FPC friendly application termination.

I've also started on COCOALOOPNATIVE, Which seems to be as a safest (and the most Cocoa friendly) approach.
As it does use native- run method, yet it doesn't hi-jack the loop to call LCL event.
https://wiki.freepascal.org/Cocoa_Internals/Application#Native_Loop_.28COCOALOOPNATIVE.29

However, at this point, COCOALOOPHIJACK is used by default

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190617/df3190d9/attachment.html>

On Sun, Jun 9, 2019 at 8:59 AM Tobias Giesen via lazarus <

Hello,

I think there's a newer version of 10.15 available. Has anyone been able to test, IF this fix is still needed?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190707/43be499a/attachment.html>