net/http: racy use of timers in http2Transport #37449
Closed
Labels
Milestone
Comments
Change https://golang.org/cl/221298 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Feb 27, 2020
If we see a racy use of timers, as in concurrent calls to Timer.Reset, do the operations in an unpredictable order, rather than crashing. Updates #37400 Updates #37449 Fixes #37494 Change-Id: Idbac295df2dfd551b6d762909d5040fc532c1b34 Reviewed-on: https://go-review.googlesource.com/c/go/+/221077 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 98858c4) Reviewed-on: https://go-review.googlesource.com/c/go/+/221298
Closed by merging 3293174 to release-branch.go1.14. |
This is now fixed on tip and 1.14 branch. |
peterebden
added a commit
to thought-machine/please-servers
that referenced
this issue
Apr 5, 2020
It appears we are affected by golang/go#37449; I have seen one panic from it so far.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
With these strategically-placed sleeps:
I get reliable crashes out of
GOTRACEBACK=system go test -race
innet/http
.The crash is a detected race between s.timer.Reset during the request writing goroutine (specifically a delayed body write) and s.timer.Stop during response processing of a 100 Continue header. Full stacks below.
The code is correct except for provoking the race panic. The timer setup is:
The request writing does:
If we get a 100 Continue then we stop the timer and run the function:
where on100 is:
The Stop is cleanup, and fnonce is protecting the actual work.
If this on100 Stop happens first, then s.timer.Stop above returns false, and s.timer.Reset does not run.
If the scheduleBodyWrite Stop happens first, then it's true that there is a race where maybe the
on100 Stop happens before the scheduleBodyWrite Reset, so that the timer still does fire after s.delay.
But the code is aware of that potential problem and using fnonce to address it.
This code is basically unchanged since it was written in 2016.
What changed is that the timers got pickier in Go 1.11.
If we don't remove the panic in #37400 then we need to rewrite this code.
The text was updated successfully, but these errors were encountered: