staticcheck: fatal error: runtime: out of memory in go1.12 #419
Comments
|
A couple of basic things:
|
Apologies. I had thought these were public (at one point they were). Will try to figure out why that's not the case and get back to you.
Sorry for noob question, but how do I go about getting you this information? |
|
Update: the logs have been made public. |
|
I'm able to access the logs, are they available to you, @dominikh? I'm not sure what could have changed between 1.11 and 1.12 to cause this. But this brings up an "interesting" point: we make the assumption that we can have all the typechecked data in memory at once. That might be a valid assumption if the project you're opening/typechecking is small enough, or if there's enough memory, but it might not be true here: I'm wondering if this is going to become a big problem as more of these tools are run in memory-constrained containers. (Though 14G is a lot.....) |
I have access to them now, yes.
To be fair, staticcheck currently makes the assumption that all ASTs, type information and SSA can be in memory at once. Memory usage should go down drastically once we migrate to the go/analysis framework.
I don't know how to do it in your Google Cloud thingy, but locally you'd invoke staticcheck via |
|
Note: we're hitting what seems to be the same problem ourselves. We blow through our 8GB of ram on travis when doing CI/CD: pulumi/pulumi#2629 Example Stack |
Do you have an expectation on when that will happen? Thanks! |
|
@CyrusNajmabadi it will likely still take several months. In the meantime I strongly recommend experimenting with |
|
I've pushed some commits that should reduce memory usage some. Nothing dramatic yet, but you may be able to save some GBs. |
|
I have the same problem. I tried updating to the latest version of staticcheck with these commands (using go mod in the project): go get -u honnef.co/go/tools
go mod vendor
go install -v -mod=vendor honnef.co/go/tools/cmd/staticcheckwich resulted in I'll check in my CI to see if it works there. For CI, I'm using drone on a machine with 16GB RAM. Update: Doesn't work on drone either. The failing CI step runs in the |
|
You seem to be using an old version of golang.org/x/tools/go/packages – the TypesSizes field was added on January 17 in b4b6fe2cb82970f144debbe03ecb71e340b15446. Please update your vendored dependencies. Also, running out of memory (what this issue is about) and failing to compile staticcheck (your comment) are not "the same problem". In the future please file a separate issue. |
|
I'm going to merge this issue into #376. Once we finish the port, memory usage will be greatly reduced. |
OS: Ubuntu 14.04.5 LTS
Memory: 14.68GB
Proc Logical CPUs: 4
Go version: go version go1.12 linux/amd64
Staticcheck version (in go.mod): honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a
When I run
staticcheck ./...at the root of cloud.google.com/go, I get:When I run the exact same set of commands in go version go1.11.5 linux/amd64, it works. I have tried both several times and the results are consistent.
Link to 1.12 (failing) log: https://source.cloud.google.com/results/invocations/89398127-b9a7-49d4-befe-c9abbce087c9/targets
Link to 1.11 (passing) log: https://source.cloud.google.com/results/invocations/a80c20a8-7aad-4b3c-a79a-9f7529ba7844/targets
I loosely wonder whether there might be a regression in types/ast or some other stdlib package that is greatly reducing memory efficiency. cc @matloob
Might be related to #377
The text was updated successfully, but these errors were encountered: