Skip to content
This repository was archived by the owner on Dec 18, 2018. It is now read-only.

Flaky Test: Kestrel.FunctionalTests sometimes fails with "unable to communicate with test host process" or assert #1616

Closed
mikeharder opened this issue Apr 6, 2017 · 10 comments
Assignees

Comments

@mikeharder
Copy link
Contributor

mikeharder commented Apr 6, 2017

Kestrel.FunctionalTests sometimes fails with "unable to communicate with test host process" (on netcoreapp2.0) or an assert (net46). A workaround is to use release instead of debug (build.cmd /p:Configuration=Release).

Assert

Block being leased from disposed pool!
   at Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.MemoryPool.Lease()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.MemoryPool.Rent(Int32 size)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.AllocateWriteHeadUnsynchronized(Int32 count)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.IPipeWriter.Alloc(Int32 minimumSize)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.AdaptedPipeline.<ReadInputAsync>d__10.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.AdaptedPipeline.ReadInputAsync()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.AdaptedPipeline.<RunAsync>d__9.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.AdaptedPipeline.RunAsync()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.FrameConnection.<RunAdaptedPipeline>d__26.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.FrameConnection.RunAdaptedPipeline()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.FrameConnection.<ApplyConnectionAdaptersAsync>d__25.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.FrameConnection.ApplyConnectionAdaptersAsync()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.FrameConnection.<>c.<StartRequestProcessing>b__20_0(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

CI Build Failure

http://aspnetci/viewLog.html?buildId=197746&tab=buildLog&buildTypeId=XPlat_Linux_UbuntuUniverseCoreCLR&logTab=tree&filter=important&consoleStyle=true#_focus=93201

@mikeharder mikeharder changed the title Flaky Test: Kestrel.FunctionalTests sometimes fails with "unable to communicate with test host process" Flaky Test: Kestrel.FunctionalTests sometimes fails with "unable to communicate with test host process" or assert Apr 6, 2017
@cesarblum cesarblum added this to the 2.0.0 milestone Apr 7, 2017
@muratg muratg assigned halter73 and unassigned halter73 Apr 7, 2017
@muratg muratg assigned halter73 and unassigned cesarblum Apr 10, 2017
@davidfowl
Copy link
Member

This is fixed with 58284bd

@davidfowl
Copy link
Member

Nope, I can still reproduce it.

@davidfowl
Copy link
Member

davidfowl commented Apr 11, 2017

As described today by @halter73 this is happening because of a race between when the connection closes and when the libuv connections are walked during shutdown. Normally, the shutting down the server waits a for a certain amount of time before ending all connections, but since we made the change to immediately abort the connection on on a FIN, we lose track of that connection even though we may still be in the process of setting up the FrameConnection. This seems to be causing a bunch of random test failures.

  • Since the server doesn't wait on connections we can run the connection adapters after the uv_loop shuts down causing the debug assert here.

@natemcmaster
Copy link
Contributor

Hit same error just now, but stack trace came from Frame.ProduceEnd.

@davidfowl
Copy link
Member

@natemcmaster Can you paste it?

@natemcmaster
Copy link
Contributor

sadly I don't have it anymore. Was about to copy/paste it when the dialogue box window was closed due to testhost.exe dying.

@natemcmaster
Copy link
Contributor

The RequestTests.LargeUpload test just triggered this failure. Stack trace matched the one Mike shared in original post. It didn't include Produce.End this time.

@Tratcher
Copy link
Member

@Tratcher
Copy link
Member

http://aspnetci/viewLog.html?buildId=204841&buildTypeId=CoreCLR_Linux&tab=buildLog#_focus=38604

Unhandled Exception: System.ObjectDisposedException: Safe handle has been closed   at
System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)   at 
System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)   at 
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.LibuvFunctions.NativeMethods.uv_async_send(UvAsyncHandle handle)   at 
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.LibuvFunctions.async_send(UvAsyncHandle handle)   at 
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.UvHandle.ReleaseHandle()   at System.Runtime.InteropServices.SafeHandle.InternalFinalize()   at 
System.Runtime.InteropServices.SafeHandle.Finalize()

@halter73
Copy link
Member

Should be fixed by #1707. I'll reopen if we see this kind of failure again.

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

6 participants