P/Invoke function returning SafeSocketHandle throws "System.MissingMethodException: .ctor"

[asmichi]

Description

On .NET 5, P/Invoke function returning SafeSocketHandle throws "System.MissingMethodException: .ctor". See MissingSafeSocketHandleCtor.zip for a full repro project.

    public static class Program
    {
        private const int AF_INET = 2;
        private const int SOCK_STREAM = 1;

        public static void Main()
        {
            // System.MissingMethodException: '.ctor'
            // (This returns -1 because we have not initialized WinSock2; that does not matter, though.)
            var sock = socket(AF_INET, SOCK_STREAM, 0);
            sock.Dispose();
        }

        [DllImport("Ws2_32.dll")]
        public static extern SafeSocketHandle socket(int af, int type, int protocol);
    }

Configuration

• .NET SDK 5.0.100
• Windows 10 Pro x64 (20H2, 19042.630)

Regression?

Yes. Worked on 3.1.404.

Other information

The SafeHandle doc says "You should also provide a parameterless constructor".

A parameterless ctor is defined in the SafeSocketHandle source file but missing from the released assembly at "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0\System.Net.Sockets.dll".

I do not think this is an intended behavior. I do now know the root cause, though.

Stack traces:

Unhandled exception. System.MissingMethodException: .ctor
   at ConsoleAppSafeSocketHandle.WinSock2.socket(Int32 af, Int32 type, Int32 protocol)
   at ConsoleAppSafeSocketHandle.Program.Main()

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

On .NET 5, P/Invoke function returning SafeSocketHandle throws "System.MissingMethodException: .ctor". See MissingSafeSocketHandleCtor.zip for a full repro project.

    public static class Program
    {
        private const int AF_INET = 2;
        private const int SOCK_STREAM = 1;

        public static void Main()
        {
            // System.MissingMethodException: '.ctor'
            // (This returns -1 because we have not initialized WinSock2; that does not matter, though.)
            var sock = socket(AF_INET, SOCK_STREAM, 0);
            sock.Dispose();
        }

        [DllImport("Ws2_32.dll")]
        public static extern SafeSocketHandle socket(int af, int type, int protocol);
    }

Configuration

• .NET SDK 5.0.100
• Windows 10 Pro x64 (20H2, 19042.630)

Regression?

Yes. Worked on 3.1.404.

Other information

The SafeHandle doc says "You should also provide a parameterless constructor".

A parameterless ctor is defined in the SafeSocketHandle source file but missing from the released assembly at "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0\System.Net.Sockets.dll".

I do not think this is an intended behavior. I do now know the root cause, though.

Stack traces:

Unhandled exception. System.MissingMethodException: .ctor
   at ConsoleAppSafeSocketHandle.WinSock2.socket(Int32 af, Int32 type, Int32 protocol)
   at ConsoleAppSafeSocketHandle.Program.Main()

Author:	asmichi
Assignees:	-
Labels:	area-System.Net.Sockets, untriaged
Milestone:	-

[asmichi]

I just wanted to bring this to your attention. Something seems wrong with the released assemblies.

This issue itself is not a blocking issue to me because this issue is easy to work around. It is even acceptable to me if this is marked as an unsupported use case (by design).

[GrabYourPitchforks]

Possible linker issue? I'd think the linker would special-case SafeHandle-derived types and not remove the ctors, but possible something went wrong in this instance.

/cc @marek-safar @MichalStrehovsky

[marek-safar]

Yep, see dotnet/linker#1660

[stephentoub]

@marek-safar, so even though the ctor exists:

runtime/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SafeSocketHandle.cs

Line 41 in dc0e11d

private SafeSocketHandle() : base(ownsHandle: true) => OwnsHandle = true;

the linker is trimming it out in the assembly build because no P/Invokes are using it in the assembly build?

This should be fixed in servicing; I'm not sure how that works. Can we service the linker and then service release/5.0 to use the updated linker?

[GrabYourPitchforks]

As a follow-up, we should diff all (incl. non-public) members of the runtime + BCL's pre-trimmed DLLs and post-trimmed DLLs. Could help identify other places where we've inadvertently made a break.

[MichalStrehovsky]

the linker is trimming it out in the assembly build because no P/Invokes are using it in the assembly build?

Yeah, I assume this code would cover it if the SafeHandle was actually used in a p/invoke:

https://github.com/mono/linker/blob/b24d0e663d5bf4772b0896e2bc3dab3391fae744/src/linker/Linker.Steps/MarkStep.cs#L2647-L2648

It happens to cover safe handles and things like blittable classes. If the SafeHandle is actually used in a p/invoke, linker will keep it. But it's not used in a p/invoke during the library build.

Linker should probably treat constructors of SafeHandles the same as if they were public.

[marek-safar]

Yep, this is an actually different issue. We are trimming the constructor as part of libraries build because it's not referenced anywhere and it's private.

I don't think there is much to be fixed in the linker. The linker on final apps would work fine if the constructor was actually present in the runtime/SDK assemblies. We should fix libraries build not to trim such constructors. There are multiple ways how to do it, one of them is to change the constructor to be public.