search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.27k stars 4.73k forks source link

Port WinRT WebSockets Client fix (#21600) to UWP servicing (netcore50) branch #23923

Closed Trolldemorted closed 4 years ago

Trolldemorted commented 7 years ago

As as been reported here, if the connection of a ClientWebSocket in NETStandard16 is terminated, the process will crash because the exception cannot be handled.

This issue has been adressed in NETStandard20/UWP6.0 and the FCU, and it works if you target W10 build 16299 on a desktop. However, on W10M devices like the Lumia 640, the build and thus NETStandard20 is unavailable and everytime a connection is disrupted the app will crash.

Could a fix for this be made available, preferably in the near future? Seeing your app being killed without anything you can do for several months because of a known and identified issue is tiresome.

lwansbrough commented 7 years ago

I'm not sure if this is the exact same issue or not.

I'm running a .NET Core 2.0 CLI app.

What I'm noticing is if the remote host abruptly closes the connection, and I attempt to call SendAsync or ReceiveAsync immediately thereafter (I'm in a multi-threaded environment so this is possible), I receive a non-.NET exception.

Here's what that looks like:

dotnet(75902,0x700010355000) malloc: *** error for object 0x7fe5669dbf20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

This of course, is uncatchable.

davidsh commented 7 years ago

dotnet(75902,0x700010355000) malloc: error for object 0x7fe5669dbf20: pointer being freed was not allocated set a breakpoint in malloc_error_break to debug

That exception above is not related to this open issue.

This issue is only about Windows 10 UWP apps (which use the WinRT WebSockets implementation underneath System.Web.WebSockets.Client).

lwansbrough commented 7 years ago

@davidsh Ok, I'll create a new issue. Thanks.

davidsh commented 7 years ago

cc: @weshaggard @karelz This issue is a request for a servicing backport of a UWP bug in .NET Core (UWP implementation only) presumably in the .NET Core 1.0 or 1.1 branch. Fixing this would require a backport of the fix itself plus a rebuild of the System.Net.WebSockets.Client NuGet package. Also, might need to have to update any other meta-packages as well.

Trolldemorted commented 7 years ago

If you don't release a backport of the fix to 1.x you might want to remove System.Net.WebSockets.Client's public listing. On NETStandard20 the classes are included anyways, and I believe every platform except those suffering from the bug are able to use NETStandard20, so there should be no benefit from its existence.

Is full NETStandard20 support for every w10 device out of the question? Platforms and devices being left behind really restrains the standard's usefulness, as we developers will be stuck with ancient releases forever.

davidsh commented 7 years ago

Is full NETStandard20 support for every w10 device out of the question?

In terms of UWP apps, the requirement currently is that NETStandard20 requires Windows 10 Fall Creators Update. That is unlikely to ever change due to architectural differences.

In terms of non-UWP apps, NETStandard20 runs on a variety of Windows OS versions including Windows 7, etc.

cc: @terrajobst @richlander

davidsh commented 7 years ago

cc: @DavidGoll

karelz commented 7 years ago

@davidsh @DavidGoll for a 1.x hotfix, it would be good to understand the impact on customers -- how many apps/customers are impacted and how often? (those which cannot upgrade to UWP6.0 on FCU)

Is it possible for apps to use their own patched build of the lib? (might be viable temporary workaround, until we get data on impact)

Trolldemorted commented 7 years ago

One of our devs downloaded the mopbile 15254 emulator (which has W10M's FCU) and noticed that UniversalApiContract 5/UWP6/NETStandard20 is not supported.

So I assume all w10m devices are affected, and the bug occurs everytime a websocket is closed by the server or a connection failure occurs.

joshfree commented 7 years ago

@zamont

aka-STInG commented 6 years ago

Hi, any ETA when System.Net.WebSockets.Client v4.3.2 will be available on nuget.org?

davidsh commented 6 years ago

Hi, any ETA when System.Net.WebSockets.Client v4.3.2 will be available on nuget.org?

We think sometime within the next week. We are doing final testing of packages.

davidsh commented 6 years ago

cc: @weshaggard

davidsh commented 6 years ago

The updated packages went live today:

https://www.nuget.org/packages/System.Net.WebSockets.Client/4.0.2 https://www.nuget.org/packages/System.Net.WebSockets.Client/4.3.2

The 4.0.2 package is based on the release/1.0.x servicing branch. The 4.3.2 package is based on the release/1.1.x servicing branch. In terms of UWP payload, they are identical. Please pick the package based on what your app is currently pulling in for other package references. Most customers can just reference the 4.0.2 package for their UWP app.

You will need to add explicit references to one of these System.Net.WebSockets.Client packages because the current UWP meta-packages hasn't been updated yet to link to the newer WebSocket.Client package.