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: temporary directories left behind on windows-amd64-2012 builder #30789

Open
bcmills opened this Issue Mar 12, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@bcmills
Copy link
Member

bcmills commented Mar 12, 2019

The logs for the windows-amd64-2012 builder (and only that builder, as far as I can tell — CC @alexbrainman) show many flakes at the end of the cmd/go tests, of the form:

2019/03/12 20:59:55 unexpected files left in tmpdir: [go-build421361794 go-build697015714]

(https://build.golang.org/log/177e49c04af866fec137d316334a80a1a5137376)

The test otherwise seems to pass.

That log line comes from here (CC @ianlancetaylor):

log.Fatalf("unexpected files left in tmpdir: %v", names)

The fact that the temporary directories start with the prefix go-build suggests that they come from here:

tmp, err := ioutil.TempDir(os.Getenv("GOTMPDIR"), "go-build")

I'm not sure what to make of the fact that those flakes are specific to the one builder. Perhaps there is a kernel quirk on that specific version of Windows that causes it not to clean up completely on exit?

(CC @jayconrod)

@alexbrainman

This comment has been minimized.

Copy link
Member

alexbrainman commented Mar 13, 2019

The logs for the windows-amd64-2012 builder (and only that builder

Strange. I cannot explain why windows-amd64-2012 builder is different from others.

The fact that the temporary directories start with the prefix go-build suggests that they come from here:

I did not debug this failure. But, generally, you cannot delete directory, if some process have open files in that directory. Same if some process current directory is set to directory being deleted or any directory under.

I suppose someone needs to reproduce this, and then somehow debug this. Once we know how it happens, we might understand better why only windows-amd64-2012 have the problem.

Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.