aspnetcore: Test failures due to System.InvalidOperationException : Memory pool with active blocks is being disposed, 302 of 303 returned
I can pretty regularly reproduce test failures running the components tests with this message by running the tests in the components solution under the debugger.
Microsoft.AspNetCore.Components.E2ETest.ServerExecutionTests.LocalizationTest.CanSetCultureAndReadLocalizedResources(culture: "en-US", message: "Hello!")
Source: LocalizationTest.cs line 38
Outcomes
1 Passed
1 Failed
Results
1) Microsoft.AspNetCore.Components.E2ETest.ServerExecutionTests.LocalizationTest.CanSetCultureAndReadLocalizedResources(culture: "en-US", message: "Hello!")
Duration: 29 sec
2) Microsoft.AspNetCore.Components.E2ETest.ServerExecutionTests.LocalizationTest.CanSetCultureAndReadLocalizedResources(culture: "en-US", message: "Hello!")
Duration: 1 ms
Message:
[Test Class Cleanup Failure (Microsoft.AspNetCore.Components.E2ETest.ServerExecutionTests.LocalizationTest)]: System.InvalidOperationException : Memory pool with active blocks is being disposed, 302 of 303 returned
Stack Trace:
MemoryPoolThrowHelper.ThrowInvalidOperationException_DisposingPoolWithActiveBlocks(Int32 returned, Int32 total, DiagnosticPoolBlock[] blocks) line 62
DiagnosticMemoryPool.Dispose(Boolean disposing) line 119
MemoryPool`1.Dispose()
SocketConnectionListener.DisposeAsync() line 144
KestrelServer.StopAsync(CancellationToken cancellationToken) line 190
KestrelServer.StopAsync(CancellationToken cancellationToken) line 162
KestrelServer.Dispose() line 211
ServiceProviderEngineScope.DisposeAsync()
--- End of stack trace from previous location where exception was thrown ---
WebHost.DisposeServiceProviderAsync(IServiceProvider serviceProvider) line 384
WebHost.DisposeAsync() line 375
WebHost.Dispose() line 358
WebHostServerFixture.Dispose() line 27
ToggleExecutionModeServerFixture`1.Dispose() line 61
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 20 (16 by maintainers)
@sh-erfan Do you have any logs? This is expected behavior if an ongoing request takes longer than the ShutdownTimeout (defaults to 5 seconds). You can use IHostApplicationLifetime.ApplicationStopping to observe this and cancel the request gracefully before the timeout.
Even after the ShutdownTimeout expires, Kestrel gives another (nonconfigurable) 1 second grace period after closing all its sockets before it disposes the memory pool. In many cases this is enough time for middleware to observe an IOException and exit, but that is definitely not guaranteed to work. For example, middleware doing some operation that takes over 6 seconds before first writing to a response or middleware delaying over a second between writing without observing ApplicationStopping could run into this MemoryPool ODE.