Closed heymind closed 2 years ago
Thank you for the bug report! We took a few minutes to look over the stack trace and the implementation of the readers and writers involved here.
From what we can tell, the issue does not seem to be the recvBuf
capacity. It seems like the io.ReadWriteCloser
that is being passed as the first conn
argument to https://pkg.go.dev/github.com/hashicorp/yamux#Server may not correctly implement the io.Reader
interface. Ref: https://pkg.go.dev/io#Reader
It seems like a read call to that reader is returning a number that is too large for "number of bytes read" (the n
return value). This is causing the bufio.Reader
to attempt to read past the capacity of the bytes.Buffer
, which produces this panic. The relevant lines are here:
https://cs.opensource.google/go/go/+/refs/tags/go1.17.2:src/bufio/bufio.go;l=213-218
We expect that the reader should only return up to length
bytes, because it is wrapped in an io.LimitedReader
, but looking at https://cs.opensource.google/go/go/+/refs/tags/go1.17.2:src/io/io.go;l=461, we can see that all LimitedReader
does is resize the slice, it don't force the underlying reader to limit its read, and it never validates the n
that it gets back.
Is the conn io.ReadWriteCloser
you pass in a custom implementation of io.ReadWriteCloser
or from the stdlib? Does this explanation seem like it might explain the panic?
As far as we can tell at this point, it does not seem to be a bug in yamux.
Closing due to lack of response.
I'm working on a reverse proxy server via websocket and this great library is used as a multiplexer over single ws connection. It works fine when proxying small http request but will panic if body is large.
https://github.com/hashicorp/yamux/blob/26ff87cf94932a054bffb8b8e926d94d44558b4d/stream.go#L471-L475
Maybe we should grow it's
recv buffer
large enough to avoid panics? I have tried this modification and it never panics again. But I don't know whether makes it right.