Apple Silicon native function pointer callback throws null reference exception

After buying an Apple Silicon machine and spending the entire day debugging to check out a report of Unity builds using Rewired crashing on Apple Silicon (Rewired OSX is all managed code with native code implemented as P/Invoke calls, so theoretically it should just work but that is not the case, as usual), I have discovered the underlying cause:

Unity Mono builds crash when a native function calls back into managed code.

The exact same code works on x86 Mono and IL2CPP builds, on x86 Mono in the editor, Apple Silicon Mono in the Unity editor, and Apple Silicon in IL2CPP builds. The only scenario where it crashes Apple Silicon Mono builds.

Bug report filed.

 

Okay, good to know. Thank you! Sorry for the double report.

 

I was just wondering... the bug tracker says planned for 2020.3, but do you know if the fix might make it into a 2020.2.x minor update any time soon? we're on the latest at time of writing 2020.2.7 but still no sign of the fix and eagerly awaiting it. There's many devs stuck by this Mono PInvoke issue, and in our case IL2CPP is also not a viable option for us due to another breaking issue on that side of things. It'd be great to know if possible, thanks!

 

Ohh... that's fantastic news, cheers!

 

Ahh yup no worries, still great news that the 2020 LTS branch is getting close... and thanks for chasing this up it will really help in our planning, cheers.

 

Hi there,

Referring to this issue Unity Issue Tracker - [MacOS][Silicon] AOT.MonoPInvokeCallback native-to-managed callback fails with Apple Silicon when Scripting Backend is Mono (unity3d.com)

I've had no luck with MonoPInvokeCallbacks on an IL2CPP build either.
Gives me "libc++abi.dylib: terminating with uncaught exception of type Il2CppExceptionWrapper" at the line of code that would otherwise have given me a NullReferenceException in a Mono build.

Looks like its not fixed yet in 2020.3.0?

 

@Tautvydas-Zilys I see. No it does not throw an exception.
My builds are Apple Silicon + Intel, and I noticed this build doesn't have this error when I run it with "Open using Rosetta" checked. Not sure if that's relevant information.

 

Hi there, just checking in if there's an ETA on this fix? I've just checked out the 2020.3.1 release notes but couldn't spot a mention on this issue yet. Us and some other developers I know are totally stuck on being able to compile a working builds for Apple Silicon mac at the moment, IL2CPP is not an option for us either for other reasons, we're totally stuck with no possible workarounds available to us. I know it's not that simple for Unity to just push out fixes at the drop of a hat, but this one is really impacting in a major way, thanks.

 

Thank you for the update, cheers!

 

For anyone that's considering moving from Mono to IL2CPP with the macOS Xcode project you'll have some issues.

The problem is that while building the GameAssembly.dylib with "Archive" (so you can upload the App Store) the project tries to install the new library in /usr/local/lib (the default behavior for archiving dynamic libraries). The problem is that il2cpp in the GameAssembly's Run Script build phase puts the output in the configuration's build directory. This causes the install of the dynamic library to fail because it can't find the file.

The workaround is to modify a few of the Deployment settings in the GameAssembly target:

• Install Group: Set to empty string
• Install Owner: Set to empty string
• Install Permissions: Set to empty string
• Skip Install: Yes

Skipping the install prevents Xcode from trying to install something that's not there. Setting an empty string for the group/owner and permissions prevents chmod running (and failing) on something that's not there. To get an empty string, double-click on the text field, then hit the Return key when the popup appears.

We've tested this on Apple Silicon and Rewired (and everything else) seems to be working fine. Still, a change to the runtime, is a big step and I suspect that we'll move back to Mono once the fix lands.

-ch

 

Thanks for the share! I'll try this out, cheers!

 

I may have stumbled on another potential workaround to get IL2CPP working to fix the issue with GameAssembly where you get a error with 'Command /usr/sbin/chown failed with exit code 1' that could be an alternative changing these ^ Deployment install settings (maybe). It may have other implications for some xcode projects, but it seems that if you change the Xcode projects build system to the new build settings to remove the (now) deprecated legacy build system setting, the error goes away and you don't need to change these ^ deployment install settings.

It seems that when the new build system is used the Run Scripts phase behaves differently. @Tautvydas-Zilys do you know if the script that runs in Run Script phase for mac xcode projects is actually intended to be used with the new build system and not the deprecated legacy one that is set by default? and do you see any potential issues with using the new build system?

More discussion on the build system setting here: https://forum.unity.com/threads/xcode-legacy-build-system-is-deprecated.999532/

edit: btw - the workaround to edit the deployment settings for GameAssembly did work for me also, but left me wondering if that could also have any implications?!