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

Class Vector3 field assignation overwrites the next field's contents when using LLVM AOT #110820

Open
rolfbjarne opened this issue Dec 18, 2024 · 7 comments
Labels
area-Codegen-LLVM-mono untriaged New issue has not been triaged by the area owner

Comments

@rolfbjarne
Copy link
Member

From @jeromelaban on Wed, 18 Dec 2024 15:09:40 GMT

Apple platform

iOS, macOS, Mac Catalyst, tvOS

Framework version

net9.0-*

Affected platform version

9.0.101

Description

When a class contains two consecutive Vector3 fields, setting the value for the first will modify the first inner field (X) of the second field.

Steps to Reproduce

Add the following code to an app, then run, the error message should not happen:

public partial class MyTestClass
{
    private Vector3 _offset;
    private Vector3 _scale = new Vector3(1, 1, 1);

    internal static void RunTest()
    {
		var v1 = new MyTestClass();
		System.Console.WriteLine($"Scale: {v1.Scale} Offset: {v1.Offset} Scale: {v1.Scale}");

		var v2 = new MyTestClass() { Offset = new(1.1f, 1.1f, 5.0f) };
		System.Console.WriteLine($"Scale: {v2.Scale} Offset: {v2.Offset} Scale: {v2.Scale}");

		if(v2.Scale != new Vector3(1, 1, 1))
                {
			System.Console.WriteLine("Error: Scale is not 1, 1, 1");
                }
    }

    public Vector3 Offset
    {
        get => _offset;
        set
        {
            System.Console.WriteLine($"Before Offset: {Offset} Scale: {Scale}");

            _offset = value;

            System.Console.WriteLine($"After Offset: {Offset} Scale: {Scale}");
        }
    }

    public Vector3 Scale => _scale;
}

Repro project: 21825-iosllvmissue.zip

Did you find any workaround?

Adding a field of another type in between seems to works around the issue.

Relevant logs

No response

Copied from original issue xamarin/xamarin-macios#21825

@rolfbjarne
Copy link
Member Author

From @rolfbjarne on Wed, 18 Dec 2024 19:00:24 GMT

I can reproduce this in the iOS simulator, by building like this:

dotnet build /p:Configuration=Release -f net9.0-ios

Output:

Scale: <1, 1, 1> Offset: <0, 0, 0> Scale: <1, 1, 1>
Before Offset: <0, 0, 0> Scale: <1, 1, 1>
After Offset: <1.1, 1.1, 5> Scale: <0, 1, 1>
Scale: <0, 1, 1> Offset: <1.1, 1.1, 5> Scale: <0, 1, 1>
Error: Scale is not 1, 1, 1

Moving to dotnet/runtime, since this looks like a codegen issue.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Dec 18, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Dec 18, 2024
@jeromelaban
Copy link
Contributor

As an update, I also tried to use my own simple version of Vector3, the issue does not happen.

@EgorBo EgorBo added area-Codegen-LLVM-mono and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Dec 18, 2024
Copy link
Contributor

Tagging subscribers to this area: @steveisok, @vitek-karas
See info in area-owners.md if you want to be subscribed.

@vitek-karas
Copy link
Member

@jkurdek Jeremi who did the Vector3 intrinsics work?

@jkurdek
Copy link
Member

jkurdek commented Dec 18, 2024

It might have been me, will look into that

@tannergooding
Copy link
Member

There's probably a mismatch between the handling for locals (where Vector3 is often given 16 bytes of storage for efficiency) as compared to the handling for fields (where it should always strictly be 12 bytes of storage).
-- This is notably how RyuJIT handles it, but I vaguely recall Mono doing something similar

@BradChase2011
Copy link

Is there a current workaround besides moving fields? Is there a current expectation of when this will be fixed? In the next .net update? This has completely killed our ios/macos development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Codegen-LLVM-mono untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

7 participants