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: Transport leaks goroutines when request.ContentLength is explicitly short #4531
Labels
Milestone
Comments
You said: > but I check the 'http://golang.org/src/pkg/net/http/transport.go', it still being there. But that is not the latest code. Much has changed in this code. Please try to reproduce with the tip version. "hg update default; cd src; ./all.bash", etc. See http://golang.org/doc/install/source Status changed to WaitingForReply. |
hi, I try as your recommended: hg clone -u release https://code.google.com/p/go cd go hg update default cd src ./all.bash I checked the code version: ~/hg/go $ hg summary parent: 15135:7e135713451d tip src: gofmt -w -s branch: default commit: 1 modified update: (current) And I run my program ‘http://play.golang.org/p/IKPtSqNs53’, the problem still exists. The number of goroutines is more than 40 now, and the connections are 'leaking' too. I checked the code and debuged with gdb, here is my preliminary analysis: There are two goroutines for a new created persistConn. The reader goroutine is stuck in readLoop():559: 557 558 for alive { 559 pb, err := pc.br.Peek(1) 560 561 pc.lk.Lock() The writer goroutine is stuck in writeLoop():661: 660 for { 661 select { 662 case wr := <-pc.writech: In my code, line 667 returned a none nil err 'http: Request.ContentLength=3 with Body length 5', the 'pc' was maked broken, and pc.bw was't flushed, so line 559 in reader goroutine would never returned. The writer goroutine go back to line 661, and stuck there. 667 err := wr.req.Request.write(pc.bw, pc.isProxy, wr.req.extra) 668 if err == nil { 669 err = pc.bw.Flush() 670 } 671 if err != nil { 672 pc.markBroken() 673 } 674 wr.ch <- err Because the persistConn was new created or picked from Transport.idleConn, no one could obtain it again, it was 'leaked', with two goroutines and one connection. |
Thanks for confirming with tip. I've changed the summary of this bug. Owner changed to @bradfitz. Status changed to Accepted. |
Fix out for review: https://golang.org/cl/6937069 Status changed to Started. |
This issue was closed by revision 7c3577e. Status changed to Fixed. |
6842 @ 0x41a716 0x4080d4 0x407d22 0x488021 0x41a8e0 # 0x4080d4 selectgo+0x384 /usr/local/go/src/pkg/runtime/chan.c:996 # 0x407d22 runtime.selectgo+0x12 /usr/local/go/src/pkg/runtime/chan.c:840 # 0x488021 net/http.(*persistConn).writeLoop+0x271 /usr/local/go/src/pkg/net/http/transport.go:791 6811 @ 0x41a716 0x4072d2 0x407718 0x4879cf 0x41a8e0 # 0x4879cf net/http.(*persistConn).readLoop+0x68f /usr/local/go/src/pkg/net/http/transport.go:778 when my program runs several hours, there're thousands writeLoop and readLoop goroutings dangling around, i think somewhere someplace transport still leaking... |
I've posted a topic on go-nuts https://groups.google.com/forum/#!topic/golang-nuts/FnJZ9iZ0i_g, thanks for your reply. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by zarcardfly:
The text was updated successfully, but these errors were encountered: