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: TestDialerDualStack fails with "i/o timeout" or "got 5.81849453s; want <= 95ms" #13324
Comments
Funny, I got "PASS: TestDialerDualStack (5.99s)" when I ran TestDialerDualStack on openbsd59-vm like the following:
and this is not related to runtime/GC stuff because I got the same result when GOGC=off. |
Hm,
|
Another on windows-386: |
cc @aclements, would you please run your failure analysis tool against this? |
Sent https://go-review.googlesource.com/24985 to demote this to a flaky test for Go 1.7. Kicking this bug down the road to Go 1.8. It would be great if somebody (@mikioh?) could investigate this. |
CL https://golang.org/cl/24985 mentions this issue. |
Only run TestDialerDualStack on the builders, as to not annoy or otherwise distract users when it's not their fault. Even though the intention is to only run this on the builders, very few of the builders have IPv6 support. Oh well. We'll get some coverage. Updates #13324 Change-Id: I13e7e3bca77ac990d290cabec88984cc3d24fb67 Reviewed-on: https://go-review.googlesource.com/24985 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Not sure if I have a spare time for this issue. FWIW, the root cause of this bug probably may lie down on the protocol stack inside kernel (IP protocol control block bookkeepers and IO event notifiers), the runtime package (are we missing some important thing on epoll/kevent usage?), or the net package (are we testing it in the wrong direction?). The first analysis would just dissect the timeout TCP connection, by scraping the TCP information inside the kernel out. |
And Darwin. I'm going to disable the test. It's not proving its worth. |
CL https://golang.org/cl/38459 mentions this issue. |
It was already marked flaky for everything but the dashboard. Remove that restriction. It's just flaky overall. It's doing more harm than good. Updates #13324 Change-Id: I36feff32a1b8681e77700f74b9c70cb4073268eb Reviewed-on: https://go-review.googlesource.com/38459 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
https://storage.googleapis.com/go-build-log/3094b3f1/linux-amd64-race_18817780.log |
Change https://golang.org/cl/82916 mentions this issue: |
Sent https://golang.org/cl/82916 for the |
This test has been getting occasional timeouts on the race builder. The point of the test is whether a file descriptor leaks, not whether the connection occurs in a certain amount of time. So use a very large timeout. The connection is normally fast and the timeout doesn't matter. Updates #13324 Change-Id: Ie1051c4a0be1fca4e63b1277101770be0cdae512 Reviewed-on: https://go-review.googlesource.com/82916 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TestDialerDualStack is commonly flaking on OpenBSD and Windows, albeit with different error messages:
https://www.google.com/search?q=TestDialerDualStack+openbsd+site%3Abuild.golang.org
https://www.google.com/search?q=TestDialerDualStack+windows+site%3Abuild.golang.org
The text was updated successfully, but these errors were encountered: