Multi-thread Kestrel crashes on x64 DNX (CLR & Core CLR) on Windows (racy)

[AspNetSmurfLab]

DNX version: 1.0.0-beta8-15616
Kestrel version: 1.0.0-beta8-15614

When using an x64 DNX (either full CLR or Core CLR) on Windows, with Kestrel configured to use multiple listener threads (IKestrelServerInformation.ThreadCount = Environment.ProcessorCount / 2), it crashes on start (before any requests are made) most times. On full CLR an assert window is show:

Exception stack trace:

System.Exception: Error -704845296  Unknown system error
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.Check(Int32 statusCode) in C:\code\github\aspnet\KestrelHttpServer\src\Microsoft.AspNet.Server.Kestrel\Networking\Libuv.cs:line 67
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.pipe_connect(UvConnectRequest req, UvPipeHandle handle, String name, uv_connect_cb cb) in C:\code\github\aspnet\KestrelHttpServer\src\Microsoft.AspNet.Server.Kestrel\Networking\Libuv.cs:line 252
   at Microsoft.AspNet.Server.Kestrel.Networking.UvConnectRequest.Connect(UvPipeHandle pipe, String name, Action`4 callback, Object state) in C:\code\github\aspnet\KestrelHttpServer\src\Microsoft.AspNet.Server.Kestrel\Networking\UvConnectRequest.cs:line 40
   at Microsoft.AspNet.Server.Kestrel.Http.ListenerSecondary.<>c__DisplayClass5_0.<StartAsync>b__0(Object _) in C:\code\github\aspnet\KestrelHttpServer\src\Microsoft.AspNet.Server.Kestrel\Http\ListenerSecondary.cs:line 44

Logged by @DamianEdwards

[halter73]

The assert failure comes after uv_pipe_connect returns a negative status (this status changes randomly from run to run) causing ListenerSecondary.DispatchPipe to be disposed in a catch block.

Despite the negative return value the uv_pipe_connect callback still gets invoked with a zero status. At this point the callback tries to use the already-disposed DispatchPipe.

Since this only seems to happen with the 64 bit libuv.dll, I think we should wait for a new build of libuv before investigating this issue further.

[halter73]

So it turns out not to be an issue with the native libuv.dll ...

[DamianEdwards]

So cryptic!!