Possible race condition

[mgravell]

Possible race condition

[mgravell]

Awesome, great to hear - and great to fix this bug; I hadn't seen it, but: quite likely it was causing some connection failures that I wasn't attributing to this, especially under load

[patricksuo]

I see the same error in v2.0.7.
EDIT:
I think I forget to cleanup and rebuild everything.

Looks good after a few round tests. Confirmed the fix.
Thanks!

[mgravell]

v2.0.7 uploaded to nuget - please let me know how you get on, and thanks for a great error report

[mgravell]

I am very intrigued! Below is mostly my thought process while reading it. Sorry if it is disjointed - that's just how I think.

It looks like the problem here is with the actual list - I can't see any other way for System.Collections.Generic.List1.get_Item(Int32 index)` to throw, when it is accessed via:

 int bufferCount = value.Count;
...
for (int i = 0; i < bufferCount; i++)
{
    ArraySegment<byte> buffer = value[i];
    RangeValidationHelpers.ValidateSegment(buffer);
    _bufferListInternal.Add(buffer);
}

so yes, I agree that the most likely problem here is somehow two threads squabbling over the same list. I'd also be happy to conclude that buffer coming out incomplete (a torn value) would be a possible cause of the second stack-trace, if we accept that the first stack-trace is caused by two threads fighting over the list.

So... how could such a thing have happened? (scratches beard)

I suspect that the problem is: in the "socket work completed synchronously case" we're recycling the buffer, but not clearing the buffer-list on the socket-args - that list is then up for grabs, and if the next IO work is also multi-buffer, we'll get into problems. Yeah, I'm pretty confident that's what has happened... fixing.

(minor edits to clarify wording - see history)

[patricksuo]

I will test it tomorrow. thank you！