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

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

Closed
ShreyasZare opened this issue Jun 14, 2020 · 11 comments

Comments

@ShreyasZare
Copy link

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.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.Net.Sockets untriaged New issue has not been triaged by the area owner labels Jun 14, 2020
@ghost
Copy link

ghost commented Jun 14, 2020

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

@ShreyasZare
Copy link
Author

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
Copy link
Member

cc: @tmds

@tmds
Copy link
Member

tmds commented Jun 15, 2020

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

@ShreyasZare
Copy link
Author

@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
Copy link
Member

tmds commented Jun 15, 2020

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
Copy link
Author

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
Copy link
Member

tmds commented Jun 19, 2020

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

@wfurt
Copy link
Member

wfurt commented Jun 19, 2020

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

@wfurt wfurt closed this as completed Jun 19, 2020
ShreyasZare added a commit to TechnitiumSoftware/DnsServer that referenced this issue Jun 20, 2020
@prezaei
Copy link

prezaei commented Aug 5, 2020

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
Copy link
Member

karelz commented Aug 9, 2020

@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.)

@karelz karelz added this to the 5.0.0 milestone Aug 18, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
@karelz karelz removed the untriaged New issue has not been triaged by the area owner label Oct 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants