ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer

[antonfirsov]

After setting / using SocketAsyncEventArgs.BufferList we should be able to revert to single-buffer mode by calling:

saea.BufferList = null;
saea.SetBuffer(...);

While working on UDP test harmonization, I discovered that this does not work with ReceiveMessageFrom on Linux. Haven't checked other Unixes.

Repro:

[Fact]
public void ReceiveMessageFromIssue()
{
    using var receiver = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    using var sender = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    using var saea = new SocketAsyncEventArgs();
    var completed = new ManualResetEventSlim();
    saea.Completed += delegate { completed.Set(); };

    receiver.Bind(new IPEndPoint(IPAddress.Loopback, 0));
    sender.Bind(new IPEndPoint(IPAddress.Loopback, 0));
    saea.RemoteEndPoint = new IPEndPoint(IPAddress.Any, 0);

    // Commenting out the following line makes the issue disappear:
    saea.BufferList = new List<ArraySegment<byte>> { new ArraySegment<byte>(new byte[1]) };

    saea.BufferList = null;
    saea.SetBuffer(new byte[1024], 0, 1024);

    sender.SendTo(new byte[1024], receiver.LocalEndPoint);
    if (receiver.ReceiveMessageFromAsync(saea)) 
        Assert.True(completed.Wait(1000), "Expected operation to complete within timeout");

    // Fails on Linux, works on Windows:
    Assert.Equal(1024, saea.BytesTransferred);
}

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

Issue Details

---

After setting / using SocketAsyncEventArgs.BufferList we should be able to revert to single-buffer mode by calling:

saea.BufferList = null;
saea.SetBuffer(...);

While working on UDP test harmonization, I discovered that this does not work with ReceiveMessageFrom on Linux. Haven't checked with other Unixes.

Repro:

[Fact]
public void ReceiveMessageFromIssue()
{
    using var receiver = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    using var sender = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    using var saea = new SocketAsyncEventArgs();
    var completed = new ManualResetEventSlim();
    saea.Completed += delegate { completed.Set(); };

    receiver.Bind(new IPEndPoint(IPAddress.Loopback, 0));
    sender.Bind(new IPEndPoint(IPAddress.Loopback, 0));
    saea.RemoteEndPoint = new IPEndPoint(IPAddress.Any, 0);

    // Commenting out the following line makes the issue disappear:
    saea.BufferList = new List<ArraySegment<byte>> { new ArraySegment<byte>(new byte[1]) };

    saea.BufferList = null;
    saea.SetBuffer(new byte[1024], 0, 1024);

    sender.SendTo(new byte[1024], receiver.LocalEndPoint);
    if (receiver.ReceiveMessageFromAsync(saea)) 
        Assert.True(completed.Wait(1000), "Expected operation to complete within timeout");

    // Fails on Linux, works on Windows:
    Assert.Equal(1024, saea.BytesTransferred);
}

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

[geoffkizer]

Good find, thanks.

[karelz]

Triage: Corner case (unlikely for customers to hit it), fine to move to Future.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.