-
Notifications
You must be signed in to change notification settings - Fork 18k
net/http: go1.6beta1, nil pointer in http.Client #13839
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
Comments
Have you run your program with the race detector? http://blog.golang.org/race-detector |
I just read the code again at the version you're using (https://github.com/golang/go/blob/8db371b3d58a1c139f0854738f9962de05ca5d7a/src/net/http/transport.go) and see no way for pc or pc.conn to be nil. Except perhaps if you're using the Transport.Dial hook and returning (nil, nil) from it. Is your code available somewhere for me to look at? |
Alternatively, are you able to reproduce with the latest code in the master branch? |
Seems it was a race issue. My stress test code is using a client library.
After protecting this whole section with a mutex I cannot reproduce the panic. (There were 2 other race conditions elsewhere as well but I think they were unrelated.) A Dial hook is set in the method Is it possible that the GC can nil things if races occur? Anyways, I'll close this issue 👍 |
If you have races, anything is possible. Even very strange things. Regularly detecting races and fixing them should always be your top priority. |
This is still an issue. This is most definitely related to unexpected connection shutdowns from the server. If the connection is being closed while the client is reading/writing. For example, in the case above (using 1.6 beta1), it stopped appearing when extending the Read and Write deadlines on the server in Now using latest using latest code in the master branch (771da53) it is still appearing even with the change above. In this case it was when the server got Killed by the system (memory pressure). Probably the same thing again, the client expected the connection to be open and was reading/writing to it. I had 3 programs running on 3 different machines with several clients running in goroutines, and they all got the same panic at the same time with exactly the same stack trace as above (although different line numbers now):
I am now using a |
I don't see how such a case is possible without data races or other bugs. Are you sure your DialTimeout hook isn't returning (nil, nil)? Can you share your code and instructions to reproduce? |
Actually, I have a potential lead now. |
CL https://golang.org/cl/18573 mentions this issue. |
Occurs sometimes under the following conditions
Clients are running on OS X 10.11.2
Server is running on Linux
Looking at the source, it seems to be than
conn
is nil:The text was updated successfully, but these errors were encountered: