net/http: deadlock after leaked transport detected in TestConsumingBodyOnNextConn

[bcmills]

2020-12-01T21:42:10-7fca39a/linux-386-longtest

This is the only failure in the logs matching the regexp (?ms)Test appears to have leaked a Transport.*test timed out. It may be a secondary failure mode associated with #42942, or a different regression from CL 213277, or a latent bug that just happened to turn up now.

CC @neild @fraenkel @bradfitz @nhooyr

[bcmills]

Marking as release-blocker for 1.16 at least until we understand whether this is a regression. (CC @golang/release)

[nhooyr]

I believe this issue is unrelated to the recent change I submitted. My change only modifies how http.Server behaves when keep alives are disabled but they are enabled in the problematic test.

[nhooyr]

As far as I can tell, the affected test also doesn't use http.Transport anywhere. It's a leak from a different test.

[nhooyr]

Ah I see, the test I submitted isn't closing rwc. Pushing a fix.

[nhooyr]

Actually nvm, the body is being closed above before being asserted into a rwc.

[nhooyr]

As far as I can tell, the affected test also doesn't use http.Transport anywhere. It's a leak from a different test.

So in order for the afterTest leak test to run, t.Short() must be false which also means the tests aren't running in parallel, so I guess I'm wrong, the test must be using http.Transport somewhere. Or there's a test that doesn't have the preceding setParallel call.

[fraenkel]

Most likely related to #42942 given the goroutine stuck on line 2605.

[toothrot]

/cc @neild

[toothrot]

Labeling as okay-after-beta1, but still considering this a release blocking issue. Please comment if you disagree.

[dmitshur]

We discussed this in a release meeting and @neild is planning to look. The goal (from #42943 (comment)) is to understand whether this is a regression. Please update this issue as needed.

[fraenkel]

This isn't a regression per say but introduced by a fix, #41600.

[neild]

I am unable to reproduce this, and believe it has been fixed by https://golang.org/cl/274973 (the fix for #42942).

[dmitshur]

I understand this issue resolved (i.e., the unusual failure was investigated, and the investigation did not uncover any new reproducible problems to fix), closing.