Closed Mikolaytis closed 5 months ago
So, it cannot be reproduced on silicon m1 macOS with nativeAOT and metal? Just to confirm that it's not a trimming issue, since we use some reflection (that should be safe) to call some APIs.
yes, arm/m1 - works fine with nativeaot + trimming and metal.
Since we are multitargeting .NET 8 now, we can probably use UnsafeAccessor instead of that reflection piece when targeting net8.0+
But I doubt that it's a trimming issue, since the app works for 30 seconds before freezing
After deep user testing we've found that issue is not caused by metal. Looks like it's a nativeAOT related issue only on x64 macos build. Not a trimming issue, because all works without nativeAOT and with trimming enabled.
Disclaimer
I know that metal backend is not stable, experimental, and not production ready. I don't require any fix for this. This issue is just a report to anyone who will get stuck in the same shit and will find this report with a workaround.
Describe the bug
We've recently moved to NativeAOT. Almost all things are perfect except receiving tons of feedback from our users that app is hanging after 30-60 seconds of work on macOS x64 machines.
Debugging this was a nightmare, because we did not have x64 mac, and debugging should be performed only after nativeAOT publish. After some days of work we know for 95% accuracy - disabling metal backend resolves the issue.
Analyzing callstacks on hang actually did not provide us any useful information. Founding that metal is the issue - was pure luck, because previously it worked awesome in the all scenarios for our app.
To Reproduce
Steps to reproduce the behavior: Publish nativeAOT app into osx-x64 arch with metal backend enabled and run it on it for some time.
Temporary fix
Disable metal backend for x64 arch on macOS only