Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/6.0.4xx-xcode14.3] [tests] Find a workaround for #xamarin/maccore@2668. #18172

Conversation

rolfbjarne
Copy link
Member

  1. Mono changed dyld lookup to start looking in directories in
    NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the
    given path is absolute 1.
  2. This turned out to break Mac Catalyst, because when a DllImport says a
    P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit",
    Mono would try loading by prefixing the directories in
    NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to
    NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load
    "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
    and things would go wrong.
  3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works
    on Ventura, but apparently not on older macOS version, because the actual
    path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit"
    (note the three initial slashes instead of a single slash).
  4. Add a second workaround, where we add a dll import resolver to load exactly
    the path we want to load.

Technical sidenote:

Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit"
turned out so bad on Mac Catalyst is not obvious. What happens is this:

  • The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")'
  • dlopen checks if this is a Mac Catalyst override of a macOS system
    framework, by prefixing "/System/iOSSupport" and trying to load that. So
    dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
    which would obviously fail.
  • Then dlopen would try a few more fallbacks, eventually trying
    "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully
    loading that library.
  • Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is
    the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit"
    is the correct version). These two libraries are incompatible, and calling
    one when you mean to call the other will do nasty things like corrupting the
    stack.

This is a backport of #18159.

…ccore@2668.

1. Mono changed dyld lookup to start looking in directories in
   NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the
   given path is absolute [1].
2. This turned out to break Mac Catalyst, because when a DllImport says a
   P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit",
   Mono would try loading by prefixing the directories in
   NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to
   NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load
   "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
   and things would go wrong.
3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works
   on Ventura, but apparently not on older macOS version, because the actual
   path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit"
   (note the three initial slashes instead of a single slash).
4. Add a second workaround, where we add a dll import resolver to load exactly
   the path we want to load.

[1]: dotnet/runtime@5a1baeb
[2]: dotnet/runtime#85255

Technical sidenote:

Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit"
turned out so bad on Mac Catalyst is not obvious. What happens is this:

* The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")'
* dlopen checks if this is a Mac Catalyst override of a macOS system
  framework, by prefixing "/System/iOSSupport" and trying to load that. So
  dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
  which would obviously fail.
* Then dlopen would try a few more fallbacks, eventually trying
  "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully
  loading that library.
* Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is
  the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit"
  is the correct version). These two libraries are incompatible, and calling
  one when you mean to call the other will do nasty things like corrupting the
  stack.

This is a backport of xamarin#18159.
@vs-mobiletools-engineering-service2
Copy link
Collaborator

✅ API diff for current PR / commit

NET (empty diffs)
  • iOS: (empty diff detected)
  • tvOS: (empty diff detected)
  • MacCatalyst: (empty diff detected)
  • macOS: (empty diff detected)

✅ API diff vs stable

.NET (No breaking changes)
  • iOS: vsdrops gist (No breaking changes)
  • tvOS: vsdrops gist (No breaking changes)
  • MacCatalyst: vsdrops gist (No breaking changes)
  • macOS: vsdrops gist (No breaking changes)
  • Microsoft.iOS vs Microsoft.MacCatalyst: vsdrops (could not create gist: file 'D:\a\1\s\change-detection\results\stable-api-comparison\diff\dotnet\iOS-MacCatalyst-diff\Microsoft.iOS.Ref\ref\net6.0\Microsoft.iOS.MacCatalyst.md' does not exist)

✅ Generator diff

Generator diff is empty

Pipeline on Agent
Hash: e48d16c0585fa323cb26311405d002ce3e1b8ac8 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

❌ [PR Build] Tests on macOS M1 - Mac Ventura (13.0) failed ❌

Failed tests are:

  • monotouch-test

Pipeline on Agent
Hash: e48d16c0585fa323cb26311405d002ce3e1b8ac8 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📚 [PR Build] Artifacts 📚

Packages generated

View packages

Pipeline on Agent XAMBOT-1009.Ventura
Hash: e48d16c0585fa323cb26311405d002ce3e1b8ac8 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌

Failed tests are:

  • introspection
  • linksdk

Pipeline on Agent
Hash: e48d16c0585fa323cb26311405d002ce3e1b8ac8 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

🚀 [CI Build] Test results 🚀

Test results

✅ All tests passed on VSTS: simulator tests.

🎉 All 77 tests passed 🎉

Tests counts

⚠️ bcl: No tests selected. Html Report (VSDrops) Download
✅ cecil: All 1 tests passed. Html Report (VSDrops) Download
✅ dotnettests: All 1 tests passed. Html Report (VSDrops) Download
✅ fsharp: All 4 tests passed. Html Report (VSDrops) Download
✅ framework: All 4 tests passed. Html Report (VSDrops) Download
✅ generator: All 1 tests passed. Html Report (VSDrops) Download
✅ interdependent_binding_projects: All 4 tests passed. Html Report (VSDrops) Download
⚠️ install_source: No tests selected. Html Report (VSDrops) Download
✅ introspection: All 4 tests passed. Html Report (VSDrops) Download
✅ linker: All 40 tests passed. Html Report (VSDrops) Download
⚠️ mac_binding_project: No tests selected. Html Report (VSDrops) Download
⚠️ mmp: No tests selected. Html Report (VSDrops) Download
⚠️ mononative: No tests selected. Html Report (VSDrops) Download
✅ monotouch: All 11 tests passed. Html Report (VSDrops) Download
✅ msbuild: All 2 tests passed. Html Report (VSDrops) Download
⚠️ mtouch: No tests selected. Html Report (VSDrops) Download
⚠️ xammac: No tests selected. Html Report (VSDrops) Download
✅ xcframework: All 4 tests passed. Html Report (VSDrops) Download
✅ xtro: All 1 tests passed. Html Report (VSDrops) Download

Pipeline on Agent
Hash: [PR build]

@rolfbjarne rolfbjarne merged commit 8940e22 into xamarin:release/6.0.4xx-xcode14.3 Apr 28, 2023
53 of 56 checks passed
@rolfbjarne rolfbjarne deleted the backport-pr-18159-to-release/6.0.4xx-xcode14.3 branch April 28, 2023 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants