NativeAOT compilation issue on IOS ARM64 - losing interface members? #92106
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsDescriptionWe have an interface type IPlatformData =
abstract member OS: OS
abstract member DeviceType: DeviceType
/// The number of pixels for each XF unit on the device
abstract member DpiScaling: ISignal<float32<pixel>>
...
type App(ipd: IPlatformData) = ...
Console.WriteLine("A OS: " + ipd.OS.ToString())
Console.WriteLine("A DeviceType: " + ipd.DeviceType.ToString())
This is referenced by an IOS project, project B. There is an implementation: The MagicWhen project B calls no interface properties directly, the app crashes in var iosPd = new IOSPlatformData();
var app = new App(iosPd);When project B calls var iosPd = new IOSPlatformData();
Console.WriteLine("B OS: " + iosPd.OS.ToString())
var app = new App(iosPd);When project B calls both properties directly, the previous line also succeeds and the app prints var iosPd = new IOSPlatformData();
Console.WriteLine("B OS: " + iosPd.OS.ToString());
Console.WriteLine("B DeviceType: " + iosPd.DeviceType.ToString());
var app = new App(iosPd);It seems like interface properties are getting stripped unless they are referenced in Project B and there is a failure to detect usage from Project A. We got one stacktrace which immediately goes from our code (line 7) into low level NativeAOT ARM64 stuff (0-6). Reproduction StepsWe don't yet have a minimal reproduction. We will try to get this when our developer with the mac is back online next week. Expected behaviorAll the writelines succeed and the app doesn't crash at any point. Actual behaviorAs above Regression?No response Known WorkaroundsNo response ConfigurationRunning on fairly modern iPads, ARM64, latest IOS. Compiled on Build process includes referencing dotnet8 in the project, and this was tested post-RC1 release. The pipeline contains "Use .NET Core sdk 8.x" and Other informationNo response
|
jkotas
removed
the
needs-area-label
|
Likely duplicate of #90333 that is fixed in .NET 8 RC2. Could you please try latest .NET 8 RC2 build? You can either install latest .NET 8 SDK RC2 from https://github.com/dotnet/installer, or upgrade just the native AOT package using instructions at https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md#using-daily-builds. |
jkotas
added
the
needs-author-action
|
This issue has been marked |
|
Thanks. We'll definitely want to be using the latest bits for our testing to be worthwhile. It took 32 attempts but we got .NET 8 SDK RC2 installing in Azure Devops. Subsequently we need to install the maui workload in order to allow the dotnet-ios build. Using fails with It seems to be getting confused with both net7 and net8 references present. |
ghost
removed
the
needs-author-action
|
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos Issue DetailsDescriptionWe have an interface type IPlatformData =
abstract member OS: OS
abstract member DeviceType: DeviceType
/// The number of pixels for each XF unit on the device
abstract member DpiScaling: ISignal<float32<pixel>>
...
type App(ipd: IPlatformData) = ...
Console.WriteLine("A OS: " + ipd.OS.ToString())
Console.WriteLine("A DeviceType: " + ipd.DeviceType.ToString())
This is referenced by an IOS project, project B. There is an implementation: The MagicWhen project B calls no interface properties directly, the app crashes in var iosPd = new IOSPlatformData();
var app = new App(iosPd);When project B calls var iosPd = new IOSPlatformData();
Console.WriteLine("B OS: " + iosPd.OS.ToString())
var app = new App(iosPd);When project B calls both properties directly, the previous line also succeeds and the app prints var iosPd = new IOSPlatformData();
Console.WriteLine("B OS: " + iosPd.OS.ToString());
Console.WriteLine("B DeviceType: " + iosPd.DeviceType.ToString());
var app = new App(iosPd);It seems like interface properties are getting stripped unless they are referenced in Project B and there is a failure to detect usage from Project A. We got one stacktrace which immediately goes from our code (line 7) into low level NativeAOT ARM64 stuff (0-6). Reproduction StepsWe don't yet have a minimal reproduction. We will try to get this when our developer with the mac is back online next week. Expected behaviorAll the writelines succeed and the app doesn't crash at any point. Actual behaviorAs above Regression?No response Known WorkaroundsNo response ConfigurationRunning on fairly modern iPads, ARM64, latest IOS. Compiled on Build process includes referencing dotnet8 in the project, and this was tested post-RC1 release. The pipeline contains "Use .NET Core sdk 8.x" and Other informationNo response
|
|
@ivanpovazan What is the best way to try daily .NET 8 RC2 build on iOS with native AOT? |
|
@charlesroddie could you please try to include net7.0 feed as well, so that the workload installation command would look like: dotnet workload install maui-ios --source https://api.nuget.org/v3/index.json --source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json --source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.jsonThat should fix the errors you are seeing. The reason why workload installation also pulls in net7.0 references is to ensure building projects configured with As an additional note, making the current preview release properly set up is unfortunately a struggle at the moment. If I am not mistaken the latest nightly release seems to be referencing Xcode 15 beta iOS builds which in turn require an upgrade of Xcode in order to build projects. /cc: @rolfbjarne |
|
One more thing you can try - if you only want to verify what @jkotas suggested works:
Do the following instead:
dotnet workload install maui-ios
<ItemGroup>
<FrameworkReference Update="Microsoft.NETCore.App" RuntimeFrameworkVersion="8.0.0-rc.2.23464.16" />
<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="8.0.0-rc.2.23464.16" />
</ItemGroup>
<PropertyGroup>
<!-- This is required to fetch RC2 builds with nuget and is equivalent to providing the feed in nuget.config file -->
<RestoreAdditionalProjectSources>https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json</RestoreAdditionalProjectSources>
</PropertyGroup>
dotnet publish -c Release -r ios-arm64 -p:PublishAot=true -p:PublishAotUsingRuntimePack=true -t:Run |
|
Thanks! That resolves the build issues. XCode 15 is on the Azure Devops build agents already so that wasn't a problem. Oddly I had to add We still get the crash on startup and when our developer with the mac is back tomorrow we can look at the logs to see if it is the same issue. It's possible that it is since the threads linked to the fix above mention default interface methods and static interface types and we don't use either of those. |
|
Here's the link to the latest minimal case that @charlesroddie and I have been able to get so far: https://github.com/SummaticLtd/iosAppMinimal I believe that using the preview features has resulted in a failure earlier on in the execution than was initially stated though. Now the |
|
@kevcrooks @charlesroddie thank you for providing the sample project, I will try to repro and get back to you. |
|
The current failure is @filipnavara I saw a thread where you used the words "linker" and "xcode 15" so tagging you here. |
I managed to reproduce your issue. There seems to be an issue with rooting the main assembly with ILLink through
<ItemGroup>
<TrimmerRootDescriptor Include="Roots.xml" />
</ItemGroup>
|
|
Thanks! Trying now. Re: TrimmerRootDescriptor, I believe we added this as an attempt to fix the original issue in this thread and have no reason to believe now that we would find it useful. |
ivanpovazan
removed
the
untriaged
I can confirm that the original issue is still present in 8.0.100-rtm.23470.21. It has slightly changed in that the loss of individual members doesn't seem to be there but rather we don't successfully get any properties of the class implementing the interface even when accessing from the same project. |
|
Would it be possible for you to update the sample project: https://github.com/SummaticLtd/iosAppMinimal in a way that reproduces the new behaviour and crashes? |
|
Updated the repo. We can confirm that it crashes after adding an interface and using it. The logs say |
|
Able to reproduce @ivanpovazan ? |
|
@charlesroddie I am sorry for the delay, but I won't be able to try it out before tomorrow as I am out of office. I will post an update as soon as possible. Thank you for understanding. |
|
I managed to reproduce the originally reported issue with the provided repro project and it seems that the issue is related to the default With the default setting: @charlesroddie to unblock your progress on this, as a workaround, could you try setting in <TrimMode>partial</TrimMode>and I will look into properly fixing this in the linker. |
|
As suspected:
This only seem to happen when referencing a F# library. We have opened #93008 to track fixing this with ILLinker. |
|
I just rebuilt and ran the app with dotnet As this seems to be fixed I am closing the issue. |
|
@ivanpovazan please could you share info on the steps we need to follow to compile? I've installed the following dotnet sdk: Is there another step we need? |
|
@kevcrooks setting up the alpha release is a bit tricky, I can look into how to set it up with the latest version and come back to you. |
|
@ivanpovazan our app seems to be working fine on dotnet8 nativeaot with workarounds to interfaces defined in F# and implemented in C#. So we should be OK until the servicing release. Thanks! |
Description
We have an interface
IPlatformDatadefined in project A, and anApptype, with some diagnosticConsole.Writelines.This is referenced by an IOS project, project B. There is an implementation:
The Magic
When project B calls no interface properties directly, the app crashes in
"A OS: " + ipd.OS.ToString():When project B calls
iosPd.OSproperties directly, the previous line succeeds and the app printsA OS: IOSand crashes in"A DeviceType: " + ipd.DeviceType.ToString():When project B calls both properties directly, the previous line also succeeds and the app prints
A OS: IOSandA DeviceType: IPad:It seems like interface properties are getting stripped unless they are referenced in Project B and there is a failure to detect usage from Project A.
We got one stacktrace which immediately goes from our code (line 7) into low level NativeAOT ARM64 stuff (0-6).
Reproduction Steps
We don't yet have a minimal reproduction. We will try to get this when our developer with the mac is back online next week.
Expected behavior
All the writelines succeed and the app doesn't crash at any point.
Actual behavior
As above
Regression?
No response
Known Workarounds
No response
Configuration
Running on fairly modern iPads, ARM64, latest IOS.
Compiled on
Build process includes referencing dotnet8 in the project, and this was tested post-RC1 release. The pipeline contains "Use .NET Core sdk 8.x" and
dotnet publish. We haven't yet reproduced when compiling from mac.Other information
No response
The text was updated successfully, but these errors were encountered: