-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Increased memory usage in 1.24.0 causing out-of-memory #994
Comments
1.24.0 causing out-of-memory see [1] so for now pin the version to 1.23.8 [1] - golangci/golangci-lint#994
in golangci-lint 1.24.0 causing out-of-memory see [1] so for now pin the version to 1.23.8 [1] - golangci/golangci-lint#994
Limit golangci-lint version to 1.23.8 due to memroy issue[1]. In addition its generaly recommended to fix the linter version to avoid unexpectedly failing on the project in case of new checks that are added. [1] golangci/golangci-lint#994
…1106) * Roll back linter version to get around memory consumption problems * Wrong go.mod
v1.24.0 has memory usage regressions: golangci/golangci-lint#994
* fix makefile: explicitly set bash as shell; tune lint. * unquote SHELL. * downgrade golangci-lint to v1.23.6. v1.24.0 has memory usage regressions: golangci/golangci-lint#994
We are also experiencing this issue. |
I think that is related to #987 |
Why you think so? |
Summary: v1.24 version of golangci-lint gets oomed killed during execution on circleci. see golangci/golangci-lint#994 for more info. Reviewed By: naor9991 Differential Revision: D20592270 fbshipit-source-id: 5a8b5f90555f18abfd0319615e9aaec1e7473ff4
Because there are some changes inside staticcheck about ssa. |
friendly ping @jirfag |
Hitting this issue constantly after upgrading to 1.14 and 1.24.0 |
The latest release of staticcheck is still 2020.1.3 as of this writing. From comment:
Past closed issues:
My understanding is that there is no open issue for the memory usage of I wonder if it might be a good idea to warn people who have |
Hey, I'm very sorry for lack of response :( You are right, this should be related to unused linter and staticcheck. Current workaround is to disable unused linter. Any PR that will help to mitigate this issue will be welcomed and reviewed ASAP. Also, please ping me instead of jirfag. |
I believe @dominikh has been recently working on improving the footprint of his tools. |
That is true. However, the vast majority of the footprint lies in how the analyses are run, i.e. the |
Would emitting a warning message whenever the linter is started while |
Generating warnings for each Feel free to send PR ⚡ |
Also it is related to #898 |
I had to downgrade Also please don't blame |
Closing for now. Please open new issue for any regression. |
The primary improvement is in early clearing of analyzed package's TypeInfo, facts, etc for whole program analyzers (`unused`). Clear it when it becomes unused and GC collects them early. Initially this clearing was performed for all analyzers except `unused`. Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4 Also in this commit: * speed up loading packages from export data (2.5s -> 2.1s for std) by not using mutex for export data since it was allowed in x/tools#07722704da13 * make an order of execution of linters stable * update renameio and robustio * use robustio in caching Relates: #987, #994, #995, #1011
Hi, Memory usage on |
The primary improvement is in early clearing of analyzed package's TypeInfo, facts, etc for whole program analyzers (`unused`). Clear it when it becomes unused and GC collects them early. Initially this clearing was performed for all analyzers except `unused`. Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4 Also in this commit: * speed up loading packages from export data (2.5s -> 2.1s for std) by not using mutex for export data since it was allowed in x/tools#07722704da13 * make an order of execution of linters stable * update renameio and robustio * use robustio in caching Relates: #987, #994, #995, #1011
The primary improvement is in early clearing of analyzed package's TypeInfo, facts, etc for whole program analyzers (`unused`). Clear it when it becomes unused and GC collects them early. Initially this clearing was performed for all analyzers except `unused`. Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4 Also in this commit: * speed up loading packages from export data (2.5s -> 2.1s for std) by not using mutex for export data since it was allowed in x/tools#07722704da13 * make an order of execution of linters stable * update renameio and robustio * use robustio in caching Relates: #987, #994, #995, #1011
The primary improvement is in early clearing of analyzed package's TypeInfo, facts, etc for whole program analyzers (`unused`). Clear it when it becomes unused and GC collects them early. Initially this clearing was performed for all analyzers except `unused`. Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4 Also in this commit: * speed up loading packages from export data (2.5s -> 2.1s for std) by not using mutex for export data since it was allowed in x/tools#07722704da13 * make an order of execution of linters stable * update renameio and robustio * use robustio in caching Relates: #987, #994, #995, #1011
Summary: v1.24 version of golangci-lint gets oomed killed during execution on circleci. see golangci/golangci-lint#994 for more info. Reviewed By: naor9991 Differential Revision: D20592270 fbshipit-source-id: 5a8b5f90555f18abfd0319615e9aaec1e7473ff4
It seems that after upgrading
golangci-lint
for my project to 1.24.0, Travis CI is no longer able to lint the project, as it fails without-of-memory
errors: https://travis-ci.org/github/flexkube/libflexkube/jobs/662847029#L1086After reverting the same PR to 1.23.8, linting passes: https://travis-ci.org/github/flexkube/libflexkube/jobs/662848310?utm_medium=notification&utm_source=github_status.
PR affected by the issue: flexkube/libflexkube#82
Offending patch (now reverted):
Thank you for creating the issue!
Please include the following information:
Version of golangci-lint
Config file
Verbose output of running
The text was updated successfully, but these errors were encountered: