net/http: Transport leaks net.Conns if connections never become idle #33849
Comments
Didn't get this fixed today, but I'm close. (I'm worried that the test will either miss a case of the leak or be flaky, so I'm trying to make sure that I actually understand the paths involved.) |
Change https://golang.org/cl/191964 mentions this issue: |
@gopherbot, please backport to Go 1.13: this is a regression from 1.12. |
This was referenced Aug 27, 2019
Backport issue(s) opened: #33877 (for 1.12), #33878 (for 1.13). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/191967 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 27, 2019
…ransport I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Cherry-picked from CL 191964. Updates #33849 Updates #33850 Fixes #33878 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 94bf9a8) Reviewed-on: https://go-review.googlesource.com/c/go/+/191967
tomocy
added a commit
to tomocy/go
that referenced
this issue
Sep 1, 2019
I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Fixes golang#33849 Fixes golang#33850 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
t4n6a1ka
added a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Fixes golang#33849 Fixes golang#33850 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The following test case fails at
go1.13rc1
due to a leak introduced in CL 184262. The leak occurs due topersistConn
pointers entering theidleConnWait
queue and remaining reachable via that queue until a connection becomes idle: if a connection never becomes idle, the queue is never cleared.The test passes with that CL reverted, but since that CL fixed a significant deadlock (#32336), I intend to fix the leak (hopefully today) rather than reverting the CL.
CC @bradfitz
The text was updated successfully, but these errors were encountered: