Block is backed by disposed slab

[davidfowl]

https://dev.azure.com/dnceng/public/_build/results?buildId=756151&view=ms.vss-test-web.build-test-results-tab&runId=23472678&paneView=debug&resultId=121832

System.AggregateException : Exceptions occurred while accessing blocks (Block is backed by disposed slab)
---- System.InvalidOperationException : Block is backed by disposed slab

  at System.Buffers.DiagnosticMemoryPool.WhenAllBlocksReturnedAsync(TimeSpan timeout) in /_/src/Shared/Buffers.MemoryPool/DiagnosticMemoryPool.cs:line 162
   at Microsoft.AspNetCore.Server.Kestrel.FunctionalTests.MaxRequestBufferSizeTests.ServerShutsDownGracefullyWhenMaxRequestBufferSizeExceeded() in /_/src/Servers/Kestrel/test/FunctionalTests/MaxRequestBufferSizeTests.cs:line 281
--- End of stack trace from previous location ---
----- Inner Stack Trace -----
   at System.Buffers.MemoryPoolThrowHelper.ThrowInvalidOperationException_BlockIsBackedByDisposedSlab(DiagnosticPoolBlock block) in /_/src/Shared/Buffers.MemoryPool/MemoryPoolThrowHelper.cs:line 57
   at System.Buffers.DiagnosticPoolBlock.GetSpan() in /_/src/Shared/Buffers.MemoryPool/DiagnosticPoolBlock.cs:line 112
   at System.Buffers.BuffersExtensions.CopyToMultiSegment[T](ReadOnlySequence`1& sequence, Span`1 destination)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal(Memory`1 destination, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.FunctionalTests.MaxRequestBufferSizeTests.<>c__DisplayClass6_0.<<StartWebHost>b__3>d.MoveNext() in /_/src/Servers/Kestrel/test/FunctionalTests/MaxRequestBufferSizeTests.cs:line 330
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequest[TContext](IHttpApplication`1 application) in /_/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs:line 659

cc @halter73

[halter73]

The timeout on this test is pretty tight. It's not surprising that it fails this way rarely, since the shutdown is meant to be abortive, the app func read loop only has a second to observe the request/connection being aborted and stop reading or else it will get this error.

I think our two options are to:

1. Stop using the DiagnosticMemoryPoolFactory in this test allowLateReturn or otherwise.
2. Make the time we wait for app funcs to complete after aborting connections configurable. See here.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ryanbrandenburg]

https://dev.azure.com/dnceng/public/_build/results?buildId=773979&view=ms.vss-test-web.build-test-results-tab&runId=24182790&resultId=122372&paneView=debug this error seems to be continuing.

[BrennanConroy]

Triage: We want to make the abort timeout internally configurable.

[davidfowl]

Can close this now. We don't have anymore slabs!