Fix Intel Mac crash: handle arch-specific DLLs in universal binary#144
Open
Fix Intel Mac crash: handle arch-specific DLLs in universal binary#144
Conversation
When xcdevice was not found (e.g., xcode-select pointing to Command Line Tools instead of Xcode.app), RunXcdeviceObserveAsync returned normally causing AppleWatchLoopAsync to immediately retry in a tight loop. This produced 165+ warnings in ~4 seconds and could exhaust resources. Fix: throw FileNotFoundException when xcdevice is missing, and catch it in the loop to break out entirely since retrying won't help until the app is restarted. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dotnet publish produces managed assemblies with ReadyToRun native code compiled for the target architecture. When creating the universal binary, the CI was copying the arm64 app as the base, so all DLLs in MonoBundle were arm64-specific. The x64 CoreCLR runtime rejected these with ERROR_BAD_FORMAT (0x8007000b), causing the app to crash on Intel Macs with 'Failed to initialize the VM'. The fix detects architecture-specific DLLs by reading the PE header machine field (0x14c = IL-only, anything else = arch-specific) and moves them into .xamarin/<RID>/ subdirectories. The macOS bootstrapper already adds both MonoBundle/ and .xamarin/<RID>/ to the Trusted Platform Assemblies list, so each architecture now loads its own compatible assemblies. Fixes #142 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add 'build-artifacts' label trigger for PR builds on all publish jobs - Add pull_request types: [opened, synchronize, reopened, labeled] - Track lipo failures with ::warning:: instead of silent || true - Copy x64-only dylibs not present in arm64 build - Merge deps.json from both architectures for complete runtime resolution Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Redth
added
build-artifacts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix Intel Mac crash in universal macOS binary
Fixes #142
Root Cause
coreclr_initializereturns0x8007000b(ERROR_BAD_FORMAT) on Intel Macs because all managed DLLs inContents/MonoBundle/are architecture-specific.When creating the universal binary, the CI copies the arm64 publish output as the base. While native dylibs are properly merged via
lipo, the 93 managed assemblies (System.Private.CoreLib.dll, MauiSherpa.MacOS.dll, etc.) contain ReadyToRun native code compiled for arm64 only. The x64 CoreCLR runtime rejects these, aborting with "Failed to initialize the VM".How it was diagnosed
lldbto break oncoreclr_initializeand captured the return code:0x8007000b=ERROR_BAD_FORMAT0xaa64for arm64,0xec20for arm64 composite R2R) instead of0x14c(IL-only).xamarin/<RID>/paths to the Trusted Platform Assemblies list.xamarin/osx-arm64/, copying x64 DLLs to.xamarin/osx-x64/, and confirming the app launches on IntelFix
After creating the universal binary (lipo for native code), the CI now:
0x14c) from MonoBundle to.xamarin/osx-arm64/.xamarin/osx-x64/The macOS bootstrapper already resolves assemblies from
.xamarin/<RID>/per-architecture subdirectories, so each architecture now loads its own compatible DLLs while pure IL assemblies remain shared in MonoBundle.