Kestrelhttpserver: 'WriteReqPool'.) (Cannot access a disposed object.

Created on 17 Sep 2016  路  10Comments  路  Source: aspnet/KestrelHttpServer

During shutdown I received these errors (version 1.1.0-alpha1-22157)

Application is shutting down...

Unhandled Exception: System.AggregateException: One or more errors occurred. (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) (Cannot access a disposed object.
Object name: 'WriteReqPool'.) ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'WriteReqPool'.
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.WriteReqPool.Allocate()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteContext.DoWriteIfNeeded()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteAllPending()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.DoPostWork()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.OnPost()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_run(UvLoopHandle handle, Int32 mode)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.run(UvLoopHandle handle, Int32 mode)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.<StopAsync>d__45.MoveNext()
   --- End of inner exception stack trace ---
   at System.ThrowHelper.ThrowAggregateException(List`1 exceptions)
   at System.Threading.Tasks.Task.WaitAll(Task[] tasks, Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.Dispose()
   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Dispose()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.Dispose()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.Dispose()
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(IWebHost host, CancellationToken token, String shutdownMessage)
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(IWebHost host)
   at AgeOfAscent.Space.Program.Main(String[] args) in D:\Work\AgeOfAscent.Space.Build\Program.cs:line 32
3 - Done bug

Most helpful comment

@ferrx This shutdown bug will be fixed in 2.0.0.

All 10 comments

Was under very high load previously

I think we need to ensure the post work queue is empty before posting the WriteReqPool disposal.

Yep.

+1
I also just run into it, the server was under no load at all at the time.

@ayende Were you referencing Kestrel 1.1.0 from NuGet.org?

Yes, more specifically:

 "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",

This might also be related, although I got it on a different machine:
https://github.com/aspnet/KestrelHttpServer/issues/1231

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]


Request finished in 3.5421ms 200 application/json; charset=UTF-8
info: Microsoft.AspNetCore.NodeServices[0]


Received SIGINT. Waiting for .NET process to exit...


Application is shutting down...


PS C:\dev\dna\project1> fail: Microsoft.AspNetCore.Server.Kestrel[0]

KestrelThread.DoPostWork
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'WriteReqPool'.
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.WriteReqPool.Allocate()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteContext.DoWriteIfNeeded()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteAllPending()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.DoPostWork()

Unhandled Exception: System.AggregateException: One or more errors occurred. (Cannot access a disposed
 object.
Object name: 'WriteReqPool'.) ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'WriteReqPool'.
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.WriteReqPool.Allocate()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteContext.DoWriteIfNeeded()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketOutput.WriteAllPending()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.DoPostWork()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.OnPost()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_run(UvLoopHandle
handle, Int32 mode)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.run(UvLoopHandle handle, Int32 mod
e)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.<StopAsync>d__45.MoveNext()
   --- End of inner exception stack trace ---

My project.assets.json file shows "Microsoft.AspNetCore.Server.Kestrel": "1.1.0"

Running in Development.

No load at all, just myself. Have WebPack's HotModuleReload running on the site with <PackageReference Include="Microsoft.AspNetCore.SpaServices" Version="1.1.0" /> but I see no evidence that's the cause.

@ferrx This shutdown bug will be fixed in 2.0.0.

Was this page helpful?
0 / 5 - 0 ratings