This is a dup of #37368, it was never fixed for me, I still end up with a few (mostly empty) /tmp/go-build* folders.
I can reproduce with current release, master and my ghetto rebased master on top of dev.go2go.
$ ls /tmp/go-build* | wc -l
2874
$ find /tmp/go-build* -type f | wc -l
261
$ ● find /tmp/go-build* -type f | tail -n 6
/tmp/go-build969177635/b001/exe/a.out
/tmp/go-build969177635/b001/importcfg.link
/tmp/go-build992265488/b001/exe/a.out
/tmp/go-build992265488/b001/importcfg.link
/tmp/go-build996176431/b001/exe/a.out
/tmp/go-build996176431/b001/importcfg.link
Comment From: OneOfOne
@stamblerre @hyangah
Comment From: stamblerre
/cc @heschik
Comment From: OneOfOne
This is still an issue, both latest release and latest master.
● ls /tmp/ | grep go-b
go-build1081835929/
go-build2583266889/
go-build293315992/
go-build3386006498/
Comment From: heschi
I think I had at some point suspected that this was a bug in the go command: it needs to call base.Exit for https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/action.go;l=273-293 to fire, and it's not totally obvious to me that it does on all code paths. But I'm not sure. I don't know how to investigate this further offhand.
I guess I can just crank the current 1-second delay up and hope that it's a timing problem.
@bcmills @jayconrod @matloob
Comment From: OneOfOne
❯ ls /tmp/ | grep go
go-build101694532/
go-build1285297711/
go-build161651095/
go-build2269050694/
go-build350919396/
go-build3747762176/
go-build447607287/
go-build638421048/
gopls-1435512.1/
gopls-1837144.1/
gopls-1913223.1/
gopls-2013061.1/
gopls-2017375.1/
gopls-2165234.1/
gopls-2187450.1/
gopls-2188351.1/
vscode-go4hQyjh/
go.049a684e4ab2ba2c4b7e59e76e2dbc2c4b8cb1b66dab78cc96925018108d750b.2776018223.mod
go.049a684e4ab2ba2c4b7e59e76e2dbc2c4b8cb1b66dab78cc96925018108d750b.3320824545.mod
go.049a684e4ab2ba2c4b7e59e76e2dbc2c4b8cb1b66dab78cc96925018108d750b.4069772916.mod
go.04e38ae1791965ced00378dd68f73bbb2a2d18f28b513ddfab42bae02b6411ca.3207838501.mod
go.04e38ae1791965ced00378dd68f73bbb2a2d18f28b513ddfab42bae02b6411ca.3207838501.sum*
gocode.vsix
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.1143449637.mod
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.1143449637.sum*
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.3404522945.mod
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.3404522945.sum*
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.880138469.mod
go.e26d71d1081531b94be31235a5f4069319715213391d0b0dc13a3ad7fdd35549.880138469.sum*
gopls.1435512-1GiB-nonames.zip
gopls.1435512-1GiB-withnames.zip
gopls.1435512-2GiB-nonames.zip
gopls.1435512-2GiB-withnames.zip
gopls.1435512-3GiB-nonames.zip
gopls.1435512-3GiB-withnames.zip
gopls.1435512-4GiB-nonames.zip
gopls.1435512-4GiB-withnames.zip
gopls.2017375-1GiB-nonames.zip
gopls.2017375-1GiB-withnames.zip
gopls.2017375-2GiB-nonames.zip
gopls.2017375-2GiB-withnames.zip
gopls.2017375-3GiB-nonames.zip
gopls.2017375-3GiB-withnames.zip
gopls.2187450-1GiB-nonames.zip
gopls.2187450-1GiB-withnames.zip
gopls.2187450-2GiB-nonames.zip
gopls.2187450-2GiB-withnames.zip
gopls.2187450-3GiB-nonames.zip
gopls.2187450-3GiB-withnames.zip
gopls.2187450-4GiB-nonames.zip
gopls.2187450-4GiB-withnames.zip
gopls.755629-1GiB-nonames.zip
gopls.755629-1GiB-withnames.zip
gopls.755629-2GiB-nonames.zip
gopls.755629-2GiB-withnames.zip
gopls.755629-3GiB-nonames.zip
gopls.755629-3GiB-withnames.zip
Still an issue.
Comment From: olivatooo
Still a big issue, when working with big libraries this eats the entire ram
Comment From: adonovan
Still a big issue, when working with big libraries this eats the entire ram
Next time it happens, could you run du -sh /tmp/gopls.* and compare with du -sh /tmp/go-build*? I suspect that the gopls files are rather larger, and I just mailed https://go.dev/cl/496191 to eliminate them.
Comment From: pjweinb
This looks like it could be closed
Comment From: adonovan
Closing due to lack of evidence of ongoing problem.