temp directories left in /tmp/

[mwat56]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • go version go1.14 linux/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
  • 1.43.2
• Check your installed extensions to get the version of the VS Code Go extension
  • 0.13.1
• Run go env GOOS GOARCH to get the operating system and processor architecture details
  • linux
    amd64

Describe the bug

After updating to Go 1.14 the same problem as in #2403 and #2442 occurred again that is hundreds of directories like ./go-build403533598 were created in /tmp and left after closing the VSCode program.

BTW: Switching OFF gopls (as discussed last year) didn't change the described behaviour, it only broke the cross-references (i.e. use F12 to jump to the source of a function).

[stamblerre]

If I recall correctly, this is caused by the go command exiting before it can clean up its temporary directories. I think @heschik dealt with this issue in gopls, so maybe he has insight on how to handle it here.

[hyangah]

@mwat56 do you use any Go tools running other than gopls, or were there any outstanding go commands (build or test...) when VS Code window was colsed?

gopls is handling this known bug of the go command (golang/go#25808) by sending an interrupt before killing the subprocesses. golang/go#37368. Other go commands or tools that use go/packages may not have the similar workaround yet.

[mwat56]

Hi @hyangah

@mwat56 do you use any Go tools running other than gopls,

Here my settings:

"go.coverOnSingleTest": true,
"go.delveConfig": {
	"dlvLoadConfig": {
		"followPointers": true,
		"maxVariableRecurse": 1,
		"maxStringLen": 128,
		"maxArrayValues": 64,
		"maxStructFields": -1
	},
	"apiVersion": 2,
	"showGlobalVariables": true
},
"go.formatTool": "goimports",
"go.gopath": "/home/matthias/devel/Go",
"go.gotoSymbol.includeImports": true,
"go.lintOnSave": "workspace",
"go.liveErrors": {
	"enabled": true,
	"delay": 1000
},
"go.useCodeSnippetsOnFunctionSuggestWithoutType": true,
"go.useLanguageServer": true,
"go.vetFlags": [
	"-all"
],
"goOutliner.extendExplorerTab": true,

or were there any outstanding go commands (build or test...) when VS Code window was colsed?

Nothing that I'm aware of.

gopls is handling this known bug of the go command (golang/go#25808) by sending an interrupt before killing the subprocesses. golang/go#37368. Other go commands or tools that use go/packages may not have the similar workaround yet.

As I mentioned before switching gopls ON or OFF doesn't change the behaviour as far as the temp files are concerned.

The only change of my system was updating to Go v1.14 therefore I suspect the problem is caused by some interaction between VSCode, its Go plugin and the Go system as such i.e. compiler, formatter etc.

[hyangah]

@mwat56 thank you for providing the details. Since you observed gopls doesn't make the problem disappear or get worse, we both agree that this is not a problem of gopls any more.

Based on the directory names, it's clear that it's left behind by go command, but nowadays,
I believe most Go analysis tools invoke the go build command behind the scene. Sorry I don't have any better idea, so throwing some random ideas here.

Maybe can you watch the /tmp/ directory for awhile and see when the directory is left behind for a while? E.g. before closing vscode, was the directory reasonably clean? etc.

Also check the Output channels (Go, Go Test, gopls, ..) frequently and see if there is any suspicious go command or tool failure message. I hope that helps you find a repro case to share with the go command team.

Experimenting after disabling some features (lint on save, live errors, goto symbol,...) and other extensions (goOutliner?) may also help narrowing down the problem.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Thank you for your contributions.