Skip to content
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: TestLocalImportsHard flaky on Windows? #17419

Closed
bradfitz opened this issue Oct 12, 2016 · 11 comments
Closed

cmd/go: TestLocalImportsHard flaky on Windows? #17419

bradfitz opened this issue Oct 12, 2016 · 11 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done. OS-Windows Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@bradfitz
Copy link
Contributor

Saw flake in a trybot run on windows-386:

--- FAIL: TestLocalImportsHard (0.68s)
    go_test.go:244: running testgo [build -o ./hard.exe testdata\local\hard.go]
    go_test.go:151: remove ./hard.exe: The process cannot access the file because it is being used by another process.
FAIL
FAIL    cmd/go  62.506s

Related: #11217 ? Similar at least.

/cc @alexbrainman

@bradfitz bradfitz added Testing An issue that has been verified to require only test changes, not just a test failure. help wanted OS-Windows labels Oct 12, 2016
@bradfitz bradfitz added this to the Go1.8 milestone Oct 12, 2016
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 12, 2016
@alexbrainman
Copy link
Member

Related: #11217 ? Similar at least.

I do not see how this is similar to #11217. In #11217 different tests were creating executable with the same name, running it and deleting it. This is not happening here. Only TestLocalImportsHard creates ./hard.exe, runs it and deletes it.

I cannot reproduce it here, but I will keep looking into it.

Alex

@mattn
Copy link
Member

mattn commented Oct 17, 2016

I'm not sure how trybot is working on gpc, when the tests got timeout, all of processes will be killed correctly?

@rsc
Copy link
Contributor

rsc commented Oct 21, 2016

@mattn, @bradfitz can say for sure, but I believe we start a whole new Windows VM for each trybot run. There shouldn't be any previous runs involved.

@alexbrainman, it's not true that only TestLocalImportsHard creates hard.exe. So does TestBadImportsHard. They should run separately, and in any case, TestLocalImportsHard should be first, and TestBadImportsHard should not begin until the former is done. Regardless, I'll send a CL using different executable names. Then maybe we can close this until we see the flake again.

@bradfitz
Copy link
Contributor Author

@mattn, @bradfitz can say for sure, but I believe we start a whole new Windows VM for each trybot run. There shouldn't be any previous runs involved.

Correct.

@alexbrainman
Copy link
Member

@alexbrainman, it's not true that only TestLocalImportsHard creates hard.exe. So does TestBadImportsHard.

Perhaps I am mistaken, but TestBadImportsHard calls copyBad (before it gets around to create hard.exe), but copyBad never returns on windows - it calls t.Skipf.

Alex

@gopherbot
Copy link

CL https://golang.org/cl/31815 mentions this issue.

@rsc rsc modified the milestones: Go1.8Maybe, Go1.8, Go1.9 Nov 11, 2016
@bradfitz
Copy link
Contributor Author

@rsc
Copy link
Contributor

rsc commented Jun 23, 2017

Cannot reproduce with:

VM=$(gomote create windows-386-gce)
gomote push $VM
gomote run $VM go/src/make.bat
gomote run -path '$WORKDIR/go/bin,$PATH' $VM go/bin/go test -run=TestLocalImportsHard -count=100 cmd/go
gomote run -path '$WORKDIR/go/bin,$PATH' $VM go/bin/go test -timeout=20m -run=TestLocalImportsHard -v -count=1000 cmd/go

@bradfitz
Copy link
Contributor Author

Just got another:

https://storage.googleapis.com/go-build-log/c2e01024/windows-amd64-gce_7605eed0.log

--- FAIL: TestLocalImportsHard (0.45s)
	go_test.go:310: running testgo [build -o ./hard.exe testdata\local\hard.go]
	go_test.go:197: remove ./hard.exe: Access is denied.
FAIL
FAIL	cmd/go	95.629s

@mattn
Copy link
Member

mattn commented Jul 13, 2017

Hmm, I ran this for 20 minutes. But it doesn't reproduce.
(FYI: I use symantec endpoint protection)

myexe.go

package main

import (
	"fmt"
	"time"
)

func main() {
	time.Sleep(time.Second)
	fmt.Println("ok")
}

test.go

package main

import (
	"fmt"
	"log"
	"os"
	"os/exec"
)

func main() {
	for {
		b, err := exec.Command("go", "build", "-o", "myexe.exe", "myexe.go").Output()
		if err != nil {
			log.Fatal(err)
		}
		b, err = exec.Command("myexe.exe").Output()
		if err != nil {
			log.Fatal(err)
		}
		fmt.Print(string(b))
		err = os.Remove("myexe.exe")
		if err != nil {
			log.Fatal(err)
		}
	}
}

@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
Copy link
Contributor

rsc commented Dec 1, 2017

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

(Starting to wonder about virus scanners.)

@rsc rsc closed this as completed Dec 1, 2017
@golang golang locked and limited conversation to collaborators Dec 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done. OS-Windows Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Development

No branches or pull requests

7 participants