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

Improved Memoryblock tracking #998

Merged
merged 3 commits into from
Jul 28, 2016
Merged

Conversation

benaadams
Copy link
Contributor

@benaadams benaadams commented Jul 20, 2016

Extending #991

In debug:

  • Adds leaser info.
  • Checks for double returns.
  • Forces finalizer to cause the finalizer check to trigger.

Also fixed 3 tests that weren't handling blocks properly.

Should resolve #988

Resolves #1012
Resolves #1013

/cc @halter73 @davidfowl @mikeharder

{
Debug.Assert(!_disposedValue, "Block being leased from disposed pool!");
#else

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move this after the doc comments or does the compiler complain about the args?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@benaadams
Copy link
Contributor Author

Turns out it doesn fix everything but it does give more info when it goes wrong, just got the following StackTrace

Unhandled Exception: System.Diagnostics.Debug+DebugAssertException: Block being garbage collected instead of returned to pool: IncomingStart, I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\SocketInput.cs, 65
   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.MemoryPool.Lease(String memberName, String sourceFilePath, Int32 sourceLineNumber) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Infrastructure\MemoryPool.cs:line 85
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketInput.IncomingStart() in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\SocketInput.cs:line 65
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.OnAlloc(UvStreamHandle handle, Int32 suggestedSize) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 199
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.AllocCallback(UvStreamHandle handle, Int32 suggestedSize, Object state) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 194
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.<>c.<.cctor>b__28_1(UvStreamHandle handle, Int32 suggestedsize, Object state) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 24
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvStreamHandle.UvAllocCb(IntPtr handle, Int32 suggested_size, uv_buf_t& buf) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvStreamHandle.cs:line 149
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvStreamHandle.<>c.<.cctor>b__24_1(IntPtr handle, Int32 suggested_size, uv_buf_t& buf) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvStreamHandle.cs:line 16
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_run(UvLoopHandle handle, Int32 mode)
   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) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\Libuv.cs:line 107
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvLoopHandle.Run(Int32 mode) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvLoopHandle.cs:line 28
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter) in I:\Work\GitHub\KestrelHttpServer\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Infrastructure\KestrelThread.cs:line 232
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

@benaadams
Copy link
Contributor Author

Hmm... got really upset with those changes?

@benaadams benaadams force-pushed the more-block-collect-info branch from d3c1876 to cbdb37a Compare July 20, 2016 22:21
@benaadams
Copy link
Contributor Author

@davidfowl @CesarBS looks like it can always trigger the issue now...

Test is: Microsoft.AspNetCore.Server.Kestrel.FunctionalTests.MaxRequestBufferSizeTests.

Alloc stack trace is:

IncomingStart, C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\SocketInput.cs, 65 ***
   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.MemoryPool.Lease(String memberName, String sourceFilePath, Int32 sourceLineNumber) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Infrastructure\MemoryPool.cs:line 85
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.SocketInput.IncomingStart() in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\SocketInput.cs:line 65
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.OnAlloc(UvStreamHandle handle, Int32 suggestedSize) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 199
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.AllocCallback(UvStreamHandle handle, Int32 suggestedSize, Object state) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 194
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Connection.<>c.<.cctor>b__28_1(UvStreamHandle handle, Int32 suggestedsize, Object state) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Http\Connection.cs:line 24
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvStreamHandle.UvAllocCb(IntPtr handle, Int32 suggested_size, uv_buf_t& buf) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvStreamHandle.cs:line 149
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvStreamHandle.<>c.<.cctor>b__24_1(IntPtr handle, Int32 suggested_size, uv_buf_t& buf) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvStreamHandle.cs:line 16
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_run(UvLoopHandle handle, Int32 mode)
   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) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\Libuv.cs:line 107
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvLoopHandle.Run(Int32 mode) in C:\projects\kestrelhttpserver\src\Microsoft.AspNetCore.Server.Kestrel\Internal\Networking\UvLoopHandle.cs:line 28
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter) in

@benaadams benaadams force-pushed the more-block-collect-info branch from cbdb37a to 415ab1f Compare July 20, 2016 22:39
@benaadams benaadams force-pushed the more-block-collect-info branch from 7f8e48f to 83cac5b Compare July 21, 2016 00:13
@benaadams
Copy link
Contributor Author

False alarm on the block, that happens after test error - is a symptom not cause.

@benaadams
Copy link
Contributor Author

@CesarBS Environment.StackTrace causes the MaxRequestBufferSizeTests to bomb; which then causes the block to finalize. Dropping the stack trace.

@benaadams benaadams force-pushed the more-block-collect-info branch from 83cac5b to f42316a Compare July 21, 2016 00:44
@benaadams
Copy link
Contributor Author

AppVeyor unrelated #1002 WritesDontCompleteImmediatelyWhenTooManyBytesIncludingNonImmediateAreAlreadyPreCompleted

@halter73
Copy link
Member

Noticed the tests in the PR as no longer slow as molasses. Nice!

#if DEBUG
public MemoryPoolBlock Lease([CallerMemberName] string memberName = "",
[CallerFilePath] string sourceFilePath = "",
[CallerLineNumber] int sourceLineNumber = 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it the switching Environment.StackTrace to this that made the tests faster?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another one of my super nits :) Put the first arg in its own line, and indent all args with 4 spaces only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Environment.StackTrace caused the large response test to crash, which then caused a block to finalize. On the one hand it crashed; on the other it finalized a block - so may still be a circumstance...

@halter73 halter73 merged commit f42316a into aspnet:dev Jul 28, 2016
@benaadams benaadams deleted the more-block-collect-info branch March 27, 2018 05:14
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants