Socket.Close() blocks indefinitely when Socket.ReceiveMessageFrom() is being called in another thread.

[ShreyasZare]

Socket.Close() blocks indefinitely when Socket.ReceiveMessageFrom() is being called in another thread in Linux on .NET Core runtime v3.1.5.

The only way to release the block that I came up with is to send any UDP packet to the listening socket so that ReceiveMessageFrom() call returns and the socket closes.

Configuration

• .NET Core runtime v3.1.5.
• Tested on Ubuntu 18.04 LTS and Raspbian Buster.
• Tested on x64 and ARM32.

Regression?

This issue as far as I can tell did not come up when the original code was written and tested on .NET Core 2.2. It started to come up when the code was upgraded to .NET Core 3.1 and redeployed.

This issue does not affect Windows installations.

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[ShreyasZare]

Update to this issue:

• The issue also affects Socket.ReceiveFrom().
• The workaround to send empty UDP packet to allow closing the socket works only for IPv4 and does not have any effect with IPv6 socket.

[stephentoub]

cc: @tmds

[tmds]

@ShreyasZare can you try using .NET 5.0 preview? It has a change to improve this specifically: dotnet/corefx#38804.

[ShreyasZare]

@ShreyasZare can you try using .NET 5.0 preview? It has a change to improve this specifically: dotnet/corefx#38804.

Thanks for the response. Good to know that the issue is being fixed in .NET 5.0 preview. I however cannot deploy with .NET 5.0 since its a product that will be distributed and is expected to work on all platforms.

I have made a few workarounds for now that work well for the specific product use cases.

[tmds]

I have made a few workarounds for now that work well for the specific product use cases.

fyi, calling Socket.Shutdown may be a workaround.
Most workarounds will be subject to subtle race conditions.

[ShreyasZare]

I have made a few workarounds for now that work well for the specific product use cases.

fyi, calling Socket.Shutdown may be a workaround.
Most workarounds will be subject to subtle race conditions.

For Udp Sockets it doesn't work. The product is actually a DHCP server so, everything it deals with is for Udp.

[tmds]

@stephentoub this can be closed. This was fixed in .NET 5.0 (dotnet/corefx#38804).

[wfurt]

Can you check 5.0 as @tmds suggested @ShreyasZare? Feel free to reopen if you see problems with it.

[prezaei]

Any plans to backport to 3.1? I am hitting a similar issue. This time with Accept on a different thread to the Dispose.

[karelz]

@prezaei any chance for you to use 5.0?
In general we do not backport fixes unless they have high impact (no workaround, multiple customers significantly affected, etc.)