-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: data race in net/http.(*expectContinueReader) #43769
Comments
Duplicate of #34902 |
Well, hrm. The same data race was reported on #34902 (in #34902 (comment)), but your report here is for |
CC @katiehockman @FiloSottile @rolandshoemaker (via CL 242598, which was intended to fix #34902) |
That fix doesn't work for this issue. The root cause is probably the concurrent writes to the same connection in ReverseProxy. |
This was fixed by CL 251858, which was backported to go1.16 but not go1.15. |
Sorry, misread the history: The fix was originally made in go1.16. It was never backported to go1.15. |
In that case, I think we can close this issue and update its milestone to Go1.16, since that's the Go release it was fixed in. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
There are two background loops for each connection. readLoop reads responses from server and writeLoop writes reqeusts to server.
In a ReverseProxy, request.Body that writeLoop used may be a
net/http.(*expectContinueReader)
. It means we must send"100 Continue"
to client if we want to read data from the body. It may lead to concurrent writes to a same connection from readLoop and writeLoop.What's worse, the connection is probably closed without waiting writeLoop to exit. After connection is closed, (*conn).bufw will be set to nil. See https://github.com/golang/go/blob/go1.15.6/src/net/http/server.go#L1690 . If writeLoop continues writing data to the connection, a panic will occur. Something like
"Invalid memory address or nil pointer dereference"
.This bug is mentioned in #29321. But that issue hasn't been updated for a long time, probably because of the label
WaitingForInfo
.Reproduce code is https://play.golang.org/p/6i3dUmUgOjK. You need to run with race detector.
What did you expect to see?
There is no data race or panic.
What did you see instead?
Data race occurred. In very rare case, this caused panic.
Data Race Output
The text was updated successfully, but these errors were encountered: