Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Receive buffers are incorrectly aliased, causing corruption of request body and framing data. #406
TL;DR I'm almost certain that BufferPool, or some misuse of it, is breaking referential transparency of ByteStrings.
Spooky debugging notes:
Notes on why the above are consistent with buffer aliasing issues:
The crucial evidence (a.k.a why did I even write all of the above?):
Some other info:
The Glorious Glasgow Haskell Compilation System, version 7.10.1
referenced this issue
Jul 28, 2015
This isn't limited to just HTTP/2, and I've got a fairly simple Application that triggers it for HTTP1. The short summary is: stream the whole request body a chunk at a time, storing both the original ByteString and a WHNF'd copy. Compare the two "copies" of the request body and respond "error" if they mismatch. This consistently says "error" for request bodies 16K bytes or larger, and consistently "good" for <= 15K request bodies.
I think this is something we can add as a test; I'll work on this and the BufferPool test this evening.
Great, the tests make it much easier to understand the context and help
I'm trying to get an exact sha1 to tag warp-3.1.
On Tue, Jul 28 2015, awpr firstname.lastname@example.org wrote:
@awpr I believe we are seeing a related issue in Servant which uses warp. Once we run our tests with warp 3.1 we have a failure on a route that has a large request body where we return [(String, [Rational])]. I would have to confirm the exact size she it fails, but this sounds related.