MacOS Sandboxed Universal Binaries Bundle is crashing on M1 devices every second launch. #69010
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsDescriptionApp is crashing with 50% repro on launch on M1 machines. From the stacktrace I think that issue is inside host's json manifest parsing. Reproduction Steps
Steps above can be skipped by downloading our app already compiled into this from: https://icons8.com/lunacy macos direct download. Or via direct link: https://lun-us.icons8.com/s/setup/Lunacy.dmg
Expected behaviorApp is launching every time without issues on M1 device. Actual behaviorApp is crashing every second time on M1 device. Regression?No response Known WorkaroundsNo response Configurationlatest released .NET 6 single bundle Other informationIf you have a question - why do you combining two binary tipes in a single bundle? - we need to support M1 ARM inside App Store. App Store can have only 1 bundle. So we need to create an universal bundle (intel/apple silicon). Also app store requires sandbox. The only way to run in sandbox is to use a single-file publish. This is the only way to get everything working. We've spent a lot of time investigating everything.
|
|
@Mikolaytis, thanks for posting the report. If you run: % COREHOST_TRACE=1 COREHOST_TRACEFILE=/tmp/Lunacy_dump /Volumes/VOLUME/Lunacy.app/Contents/MacOS/Lunacyand open
I read it here: https://developer.apple.com/forums/thread/93463, it could be related to "use after munmap". i.e. we probably need to zero out m_bundle_data ( runtime/src/native/corehost/json_parser.cpp Line 163 in e2119d4 |
5th line from the end is |
|
SDK 6.0.300 an 6.0.203 Build osx.11.0-arm64 |
|
I am able to reproduce the failure. It is not 50% chance. For me it fails about 1 out of 10 launches. But it does fail sometimes. The trace for successful and unsuccessful launches looks the same to the point of failure. |
|
It does not look like it is an issue with bundle offset calculations, since it would be failing every time. The trace reports the same computed offsets in passing or failing scenarios. |
|
53 runs and 4 errors dump file |
|
use this lipo |
|
I was unable to reproduce this with small hello-world like app. Trivial app runs hundreds of times without a failure. One theory I had is that we unmap the bundle in the |
|
I think I figured what is causing this crash. See - #69687 Now I wonder how the change can be tested with Lunacy - to be sure it indeed fixes the issue. |
|
The 6.0 change is in #69689 If you can build clr on your M1 machine, one way to try the fix is:
This is just replacing the host component in the location where SDK takes it. Generally the host must match other components like corelib, and more files need to be copied, but patching just the host might be enough here, as 6.0 does not see much churn these days. |
|
https://github.com/Mossimos/testdotnet |
|
It looks like there is another new issue unrelated to universal binaries. If I try compiling and running a singlefile helloworld app on arm64 osx with an SDK 6.0.203 or newer, I get a failure - that is without lipo. To rule out the R2R issue, it is possible to disable R2R for the local session by setting an environment variable - Another possibility is to publish trimmed at link level. |
|
Will reopen until the 6.0 fix is in. |
|
Should be done. |
|
Huge thanks for a fix! Also HUUUUGE thanks for backporting this to 6.0.7. We will try everything this week and our next app update will launch with 100% ratio. YES! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
App is crashing with 50% repro on launch on M1 machines.
From the stacktrace I think that issue is inside host's json manifest parsing.
Looks like it gets wrong position for second binary inside combined executable (x64/arm64) using
lipo.The question is - why we and our users are getting 50% of repro.
Maybe there can be a fix of hack that fixes this issue.
Reproduction Steps
osx.11.0-arm64andosx-x64platform withsingle-bundle,self-contained,trim-mode: copyused. (ReadyToRunis disabled,EnableCompressionInSingleFileis disabled).lipoand create an.applicationbundle using apple guidelines. Enable Sandbox.Steps above can be skipped by downloading our app already compiled into this from: https://icons8.com/lunacy macos direct download. Or via direct link: https://lun-us.icons8.com/s/setup/Lunacy.dmg
Expected behavior
App is launching every time without issues on M1 device.
Actual behavior
App is crashing every second time on M1 device.
Regression?
No response
Known Workarounds
No response
Configuration
latest released .NET 6 single bundle
latest released macOS
ARM64
.net6 SDK can be installed or not installed on a machine.
Other information
If you have a question - why do you combining two binary tipes in a single bundle? - we need to support M1 ARM inside App Store. App Store can have only 1 bundle. So we need to create an universal bundle (intel/apple silicon). Also app store requires sandbox. The only way to run in sandbox is to use a single-file publish. This is the only way to get everything working. We've spent a lot of time investigating everything.
The text was updated successfully, but these errors were encountered: