x/net/ipv4: flaky on Windows #17655
Comments
|
If the branch is Go 1.6 or below, it's probably because of some leaked goroutine in test cases. The testing package of Go 1.7 or above can capture such flakiness. If it happens with tip, have no clue, but we can guess that the failure happens at an intersection between testee packages and testing package. |
|
It's tip. |
quentinmit
added
the
NeedsInvestigation
|
Just took a look at testing package and I now feel like this is not an issue of ipv4 package. The interesting |
|
@aclements, is this something your tool can grep for? I'm wondering if it's happening enough to worry about. |
|
Unfortunately I don't have the logs for the x repos. |
|
@alexbrainman, are you able to reproduce this flake? |
No I cannot. But I can see different error: this is running on Windows 7. Alex |
|
You want to send a CL to t.Skip those if they get an "operation not supported" error? |
|
I can reproduce this with gomote. See the attached log.txt, which is a mystery: it has no FAIL mentions, except the end. And the there's no Exit call in the program, and there's no panic anywhere, and no log.Fatal I can see, no Main, .... I'm not sure where it's failing yet. |
Why do you think that? Maybe there's something in the net or syscall or runtime package that's crashing? Except then we'd expect some sort of stack trace, I assume. Is there something like strace for Windows, @alexbrainman? If so, probably not a CLI tool, huh? |
|
Update: If I add: func TestMain(m *testing.M) {
fmt.Println("starting test")
flag.Parse()
v := m.Run()
fmt.Println("test Run complete =", v)
os.Exit(v)
}Then it fails like: So it's not just getting killed by the kernel. The Go test does indeed intend to fail itself. But why? |
|
And verified that stderr isn't being lost: |
|
I suspected it was test failures in goroutines, so I audited all 4 in the ipv4 tests. All four looked fine. Modifying the testing package to log a stack on failure, I found: But that test looks fine: done := make(chan bool)
go acceptor(t, ln, done)
c, err := net.Dial("tcp4", ln.Addr().String())
if err != nil {
t.Fatal(err)
}
defer c.Close()
testUnicastSocketOptions(t, ipv4.NewConn(c))
<-done Where acceptor (which is only used once, and is in a separate file all by itself) is just: func acceptor(t *testing.T, ln net.Listener, done chan<- bool) {
defer func() { done <- true }()
c, err := ln.Accept()
if err != nil {
t.Error(err)
return
}
c.Close()
} It's an unbuffered channel, so I'm not sure why that synchronization isn't sufficient to make the message log something. |
|
Well, https://go-review.googlesource.com/34021 fixes the flakes, but I'm not sure why. |
|
CL https://golang.org/cl/34021 mentions this issue. |
I am not sure what you want. I have used https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx in old days. Also mksyscall._windows.go has -trace flag. Alex |
Trybots on the x/net repo sometimes flake on Windows:
https://storage.googleapis.com/go-build-log/1bd39e79/windows-amd64-gce_2c5af62a.log
But why?
That failure doesn't say much.
/cc @mikioh
The text was updated successfully, but these errors were encountered: