❔ System.IO.Pipelines cannot complete the reader
Hey. I'm having
reader.CompleteAsync throw because it tries to return an empty buffer to the array pool.
All of the reading goes successfully, but when I try to CompleteAsync the reader, it ends up in that code with an invalid state for one of the segments, apparently
Does anyone have any idea what could be up?
Approximate code is here (it doesn't contain the data structures, just shows the most important functions).
https://paste.mod.gg/wchbuamcrxfn/0BlazeBin - wchbuamcrxfn
A tool for sharing your source code with the world!
11 Replies
@Wraith2 Sorry for the ping, take a look pls if you don't mind. You might be familiar with the issue
is this your code or code from inside pipelines?
On the image the code is from the library
My code is by the link
The image might be misleading, but the stack trace shows me an
ArgumentNullException in the array pool implementation, which originated in this funcitoni'm using https://github.com/mgravell/Pipelines.Sockets.Unofficial which wraps a lot of direct access stuff for me
GitHub
GitHub - mgravell/Pipelines.Sockets.Unofficial: .NET managed socket...
.NET managed sockets wrapper using the new "Pipelines" API - GitHub - mgravell/Pipelines.Sockets.Unofficial: .NET managed sockets wrapper using the new "Pipelines" API
but pipelines is an official and supported api so if you can repro the problem open an issue and someone should look
Yeah I don't know if I will be able to reproduce this. It just happened to have worked just now. 2 times in a row. We'll see if it comes up again
Thanks for the link
And now it broke again
I don't think this can be a race condition on my side of things though. At a glance, I seem to be awaiting everything diligently. This is really strange
@Wraith2 the error seems to manifest itself only when I put a breakpoint in the code that does the parsing. If I just run it past, it works without issue
Yep, just checked it. Works without a breakpoint, doesn't work with one
It's got to be a race condition. It does sometimes trigger without a breakpoint.
in which case definately see if you can isolate a reproduction and open an issue for it, race conditions are hell in production.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.@Wraith2 It was an issue from my side after all. Basically,
AdvanceTo silently trusts the input sequence positions, it doesn't validate if they're even part of one of the buffers. Having read some of the issues on github on that, it seems like checking if an arbitrary position is in the sequence is expensive, which is why they just don't do it. I did spend a good 8 hours on debugging this though. If only there way a feature in C# to enable conditions in compiled library code without incurring a runtime cost (aka without runtime bool checks), it could be really useful here.Hmm, feels like a pit of failure it'd be good to have some sort of warning about somewhere.
but good that you got it sorted.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.