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

Mono is calling derived class function instead of base class function when base's function is invoked using delegate. #102009

Open
alhad-deshpande opened this issue May 8, 2024 · 4 comments

Comments

@alhad-deshpande
Copy link
Contributor

alhad-deshpande commented May 8, 2024

Description

Mono is calling derived class function instead of base class function when base's function is invoked using delegate. This is occurring on x86 Mono, ppc64le and s390x mono versions. The coreclr x86 version calls base class function correctly.

Reproduction Steps

Following is the program:

using System;

class A
{
    protected virtual void F() { Console.WriteLine(nameof(A)); }
}
class B : A
{
    protected override void F() { Console.WriteLine(nameof(B)); }
    static void Invoke(Delegate d) { d.DynamicInvoke(); }
    void M()
    {
        Invoke(base.F);
    }
    static void Main()
    {
        new B().M();
    }
}

Compile and Run the program on x86/ppc64le/s390x using Mono SDK.

Expected behavior

"Expected output for the program is "A"

Actual behavior

Actual output on x86 using mono sdk and on ppc64le/s390x using mono is "B".

x86_64 machine output:
[root@dotnet-x86-cent-8-stream-node5 AandBProgram]# dotnet build
MSBuild version 17.10.0-preview-24101-01+07fd5d51f for .NET
Restore complete (0.7s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
AandBProgram succeeded (4.1s) → bin/Debug/net9.0/AandBProgram.dll

Build succeeded in 5.8s
[root@dotnet-x86-cent-8-stream-node5 AandBProgram]# dotnet run
Restore complete (0.7s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
AandBProgram succeeded (0.3s) → bin/Debug/net9.0/AandBProgram.dll

Build succeeded in 1.9s
B

[root@dotnet-x86-cent-8-stream-node5 AandBProgram]# arch
x86_64

[root@dotnet-x86-cent-8-stream-node5 AandBProgram]# dotnet --version
9.0.100-preview.1.24101.1

Power machine output:
(base) root@p006vm101-ub20:~/AandBProgram# dotnet build
MSBuild version 17.8.3+195e7f5a3 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
AandBProgram -> /root/AandBProgram/bin/Debug/net8.0/AandBProgram.dll

Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:09.91
(base) root@p006vm101-ub20:/AandBProgram# dotnet run
B
(base) root@p006vm101-ub20:
/AandBProgram# arch
ppc64le
(base) root@p006vm101-ub20:~/AandBProgram# dotnet --version
8.0.100

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Cc: @uweigand

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label May 8, 2024
@Neme12
Copy link

Neme12 commented May 8, 2024

I would assume this is the expected behavior on every platform. I remember at one point having made a delegate over a virtual method and using that as a cheap-enough check as to whether the method is overridden in a derived class or not by checking the target object.

@MichalStrehovsky
Copy link
Member

I would assume this is the expected behavior on every platform. I remember at one point having made a delegate over a virtual method and using that as a cheap-enough check as to whether the method is overridden in a derived class or not by checking the target object.

The base.F syntax in C# translates to using ldftn IL instruction instead of ldvirtftn that C# normally emits for delegate creation. The delegate should point to the base method directly, not to the result of virtual resolution. The CoreCLR behavior is expected/correct, Mono behavior looks like a bug.

@janani66
Copy link

Any update on this issue?

@lambdageek
Copy link
Member

@steveisok

@lambdageek lambdageek added this to the 9.0.0 milestone May 30, 2024
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants