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

cmd/go: TestLinkXImportPathEscape flake on windows/amd64 #19491

Open
josharian opened this Issue Mar 10, 2017 · 10 comments

Comments

Projects
None yet
9 participants
@josharian
Contributor

josharian commented Mar 10, 2017

Noticed during a trybot run for CL 38006:

https://storage.googleapis.com/go-build-log/0401f0f8/windows-amd64-gce_ffacd647.log

--- FAIL: TestLinkXImportPathEscape (0.38s)
	go_test.go:260: running testgo [build -o ./linkx.exe -ldflags -X=my.pkg.Text=linkXworked my.pkg/main]
	go_test.go:167: remove ./linkx.exe: Access is denied.
FAIL
FAIL	cmd/go	83.071s

@josharian josharian added the Testing label Mar 10, 2017

@josharian josharian added this to the Go1.9Maybe milestone Mar 10, 2017

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Mar 10, 2017

remove ./linkx.exe: Access is denied.

That is what you get if you try removing executable file while program is still running.

Alex

@bradfitz

This comment has been minimized.

Member

bradfitz commented Mar 10, 2017

That doesn't appear to be the issue, since linkx.exe is never ran in that test.

The sketchy thing though is that the test is a parallel test, but the deferred cleanup method does an os.Chdir.

I haven't taken the time to gomote a test run with high -count=NNN yet to repro it, but that's my guess.

@johnsonj

This comment has been minimized.

Member

johnsonj commented Apr 28, 2017

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented May 5, 2017

linkx.exe is never ran in that test.

Why do you say that?

The sketchy thing though is that the test is a parallel test, but the deferred cleanup method does an os.Chdir.

It does not:

C:\dev\go\src\cmd\go>git diff
diff --git a/src/cmd/go/go_test.go b/src/cmd/go/go_test.go
index 0b1fe70..2a3f52e 100644
--- a/src/cmd/go/go_test.go
+++ b/src/cmd/go/go_test.go
@@ -600,13 +600,16 @@ func (tg *testgoData) wantNotStale(pkg, reason, msg string

 // cleanup cleans up a test that runs testgo.
 func (tg *testgoData) cleanup() {
+       tg.t.Logf("ALEX1\n")
        if tg.wd != "" {
+               tg.t.Logf("ALEX2\n")
                if err := os.Chdir(tg.wd); err != nil {
                        // We are unlikely to be able to continue.
                        fmt.Fprintln(os.Stderr, "could not restore working direc
                        os.Exit(2)
                }
        }
+       tg.t.Logf("ALEX3\n")
        for _, path := range tg.temps {
                tg.check(os.RemoveAll(path))
        }

C:\dev\go\src\cmd\go>go test -run=TestLinkXImportPathEscape -v
=== RUN   TestLinkXImportPathEscape
--- PASS: TestLinkXImportPathEscape (0.58s)
        go_test.go:269: running testgo [build -o ./linkx.exe -ldflags -X=my.pkg.Text=linkXworked my.pkg/main]
        go_test.go:603: ALEX1
        go_test.go:612: ALEX3
PASS
ok      cmd/go  12.654s

C:\dev\go\src\cmd\go>

a test run with high -count=NNN yet to repro it, ...

I get nothing here:

C:\dev\go\src>go test -run=TestLinkXImportPathEscape -count=1000 cmd/go
ok      cmd/go  251.248s

C:\dev\go\src>

Alex

@josharian

This comment has been minimized.

Contributor

josharian commented May 11, 2017

Two more on the front page of build.golang.org right now (testing 6897030 / CL 42430). The potentially interesting thing is that both windows-386-2008 and windows-amd64-2012 failed on the same commit. I'm not sure what they share (hardware? pods?), but tying this to some shared resource might provide a hint.

@bradfitz

This comment has been minimized.

Member

bradfitz commented May 11, 2017

They share nothing. Each Windows build is done in its own VM and then destroyed.

@johnsonj

This comment has been minimized.

Member

johnsonj commented May 22, 2017

I can repro a similar failure on a GCE buidlet (Server 2012) with 1000x runs:

$ gomote run -path  'C:/godep/gcc64/bin,$WORKDIR/go/bin,$PATH' -e 'GOROOT=C:\workdir\go' "$BUILDLET" go/bin/go.exe test -run=TestLinkXImportPathEscape -count=1000 cmd/go

--- FAIL: TestLinkXImportPathEscape (0.00s)
	go_test.go:160: GetFileAttributesEx ./linkx.exe: Access is denied.
[ repeated several times ]

@bradfitz bradfitz added the OS-Windows label May 22, 2017

@bradfitz bradfitz modified the milestones: Go1.9, Go1.9Maybe May 22, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 23, 2017

Using windows-amd64-gce builder I was unable to reproduce with:

gomote run -path '$WORKDIR/go/bin,$PATH' $VM go/bin/go test -run=TestLinkXImportPathEscape -v -count=1000 cmd/go

@rsc rsc added the help wanted label Jun 23, 2017

@broady broady modified the milestones: Go1.9Maybe, Go1.9 Jul 17, 2017

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jul 20, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 1, 2017

No update since June when I could not reproduce the problem. Timed out.

@rsc rsc closed this Dec 1, 2017

@mvdan

This comment has been minimized.

Member

mvdan commented Apr 6, 2018

This is still hitting us from time to time; these failures are all in the four most recent build.golang.org pages:

https://build.golang.org/log/4d702c4750f3910bafed225c17694a537caea679
https://build.golang.org/log/de9ece6da16cb8f3279157f69cb3f56c80363a69
https://build.golang.org/log/49fdf1941aa90a5b6d8bb5b1bd35458226860ee9
https://build.golang.org/log/d995f239f753c573137f125bdd0599b12120b883
https://build.golang.org/log/7014743d36bf8e6a15f5cda5b318a18b78951de6

Given the four Windows builders and 30 builds per page, 5 occurrences in those gives a quick and dirty ~1% failure rate. That seems problematic enough to warrant reopening and investigating further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment