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.

Sign up for GitHub

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

Jump to bottom

latest release binaries panic with Go 1.22.0 #1496

Closed
mvdan opened this issue Feb 14, 2024 · 13 comments
Closed

latest release binaries panic with Go 1.22.0 #1496

mvdan opened this issue Feb 14, 2024 · 13 comments
Labels
bug

Comments

@mvdan
Copy link
Sponsor Contributor

mvdan commented Feb 14, 2024 

$ ./staticcheck/staticcheck --version
staticcheck 2023.1.6 (v0.4.6)
$ go version
go version go1.22.0 linux/amd64
$ ./staticcheck/staticcheck ./...
panic: interface conversion: types.Object is nil, not *types.TypeName

goroutine 169 [running]:
honnef.co/go/tools/unused.(*graph).decl(0xc000bcacd0, {0x9fcd78?, 0xc000e58140}, {0x0, 0x0})
	honnef.co/go/tools@v0.4.6/unused/unused.go:1089 +0xadb
honnef.co/go/tools/unused.(*graph).entry(0xc000f95cd0)
	honnef.co/go/tools@v0.4.6/unused/unused.go:522 +0xc14
honnef.co/go/tools/unused.run(0xc000538ea0)
	honnef.co/go/tools@v0.4.6/unused/unused.go:218 +0x225
honnef.co/go/tools/lintcmd/runner.(*analyzerRunner).do(0xc000b19050, {0x9fe6a8?, 0xc000bdb220})
	honnef.co/go/tools@v0.4.6/lintcmd/runner/runner.go:992 +0x6fd
honnef.co/go/tools/lintcmd/runner.genericHandle({0x9fe6a8?, 0xc000bdb220}, {0x9fe6a8?, 0xc000274be0?}, 0x0?, 0xc000455850, 0xc000b8b9a0)
	honnef.co/go/tools@v0.4.6/lintcmd/runner/runner.go:817 +0x129
created by honnef.co/go/tools/lintcmd/runner.(*subrunner).runAnalyzers in goroutine 131
	honnef.co/go/tools@v0.4.6/lintcmd/runner/runner.go:1061 +0x6b5

The ./... above is on https://github.com/vocdoni/vocdoni-node, but I suspect many other packages run into this too.

Note that the panic goes away if I build master with Go 1.22.0 and try again, which perhaps isn't surprising given that the latest release binaries were built with Go 1.21.1. Perhaps a new release is due, with new binaries?
@mvdan mvdan added bug needs-triage Newly filed issue that needs triage labels Feb 14, 2024
@mvdan mvdan mentioned this issue Feb 14, 2024
Closed
@tomasaschan
Copy link

I am seeing a similar, but not exactly identical, nilref panic even when using go install honnef.co/go/tools/cmd/staticcheck@master:

λ go version
go version go1.22.0 linux/amd64

λ staticcheck -version
staticcheck (devel, v0.5.0-0.dev.0.20231215165614-a367d57f6820)

λ staticcheck ./...                                   
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x6e6c32]

goroutine 1555 [running]:
honnef.co/go/tools/go/ir.memberFromObject(0xc0005c6c60, {0x0, 0x0?}, {0x0?, 0x0})
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/go/ir/create.go:54 +0x52
honnef.co/go/tools/go/ir.membersFromDecl(0xc0005c6c60, {0xa04dd0?, 0xc011debf80?})
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/go/ir/create.go:155 +0x297
honnef.co/go/tools/go/ir.(*Program).CreatePackage(0xc00b0ec000, 0xc004f89560, {0xc005b36630, 0x3, 0x3}, 0xc0032c3540, 0x0)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/go/ir/create.go:207 +0x7a5
honnef.co/go/tools/internal/passes/buildir.run(0xc017c7c820)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/internal/passes/buildir/buildir.go:85 +0x165
honnef.co/go/tools/lintcmd/runner.(*analyzerRunner).do(0xc00d1a7ad0, {0xa065a8?, 0xc0231f6460})
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:992 +0x6fd
honnef.co/go/tools/lintcmd/runner.genericHandle({0xa065a8?, 0xc0231f6460}, {0xa065a8?, 0xc010dd7f40?}, 0x8beee0?, 0x0, 0xc00e98f078)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:817 +0x129
honnef.co/go/tools/lintcmd/runner.(*subrunner).runAnalyzers(0xc00029c6e0, 0xc0000b9200, 0xc0032c34a0)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:1065 +0x716
honnef.co/go/tools/lintcmd/runner.(*subrunner).doUncached(0x0?, 0xc0000b9200)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:720 +0x189
honnef.co/go/tools/lintcmd/runner.(*subrunner).do(0xc00029c6e0, {0xa065f0?, 0xc0000b9200})
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:577 +0x94b
honnef.co/go/tools/lintcmd/runner.(*Runner).Run.func2({0xa065f0?, 0xc0000b9200?})
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:1268 +0x2a
honnef.co/go/tools/lintcmd/runner.genericHandle({0xa065f0?, 0xc0000b9200}, {0xa065f0?, 0xc0000b90e0?}, 0x0?, 0xc000349510, 0xc00e9c2890)
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:817 +0x129
created by honnef.co/go/tools/lintcmd/runner.(*Runner).Run in goroutine 1
        /home/tomasl/src/pkg/mod/honnef.co/go/tools@v0.5.0-0.dev.0.20231215165614-a367d57f6820/lintcmd/runner/runner.go:1267 +0x505

Repo this happens in is unfortunately proprietary.

@Integralist
Copy link

I've got the same: fastly/cli#1130

@kachick kachick mentioned this issue Feb 15, 2024
Merged
kachick added a commit to kachick/go-tools that referenced this issue Feb 15, 2024
@kachick
go/ir: fix panic since go 1.22
5ed5e3b 
golang/tools#992d98451cb0cd4370c14e54e4262be89e83bfe2
golang/go#56010

dominikh#1495
dominikh#1496
@kachick kachick mentioned this issue Feb 15, 2024
Closed
@fgm
Copy link

fgm commented Feb 16, 2024

Similar issue, same memberFromObject function, when upgrading https://github.com/fgm/untilMongoD

After running staticcheck -debug.version the problem suddenly disappeared with no apparent reason. Maybe a compilation cache issue ?

@dominikh dominikh removed the needs-triage Newly filed issue that needs triage label Feb 16, 2024
@dominikh
Copy link
Owner

I haven't yet been able to reproduce the nil pointer dereference when running Staticcheck built with Go 1.22.

@nickcruess-soda
Copy link

nickcruess-soda commented Feb 16, 2024 •
edited

Update: little egg on my face here, we had a version inconsistency with our Github workflow yml files that was causing this error. If you have a similar issue where you're encountering a panic in a Github workflow but can't reproduce locally, double check your version consistency.

Leaving my original post for visibility

We're able to reproduce this in a proprietary repository, but only running in a Github Action running linux/amd64. Locally on Apple silicon darwin/arm64 it runs without issue.

staticcheck --debug.version output:

staticcheck 2023.1.6 (v0.4.6)

Compiled with Go version: go1.22.0
Main module:
	honnef.co/go/tools@v0.4.6 (sum: h1:oFEHCKeID7to/3autwsWfnuv69j3NsfcXbvJKuIcep8=)
Dependencies:
	github.com/BurntSushi/toml@v1.2.1 (sum: h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=)
	golang.org/x/exp/typeparams@v0.0.0-20221208152030-732eee02a75a (sum: h1:Jw5wfR+h9mnIYH+OtGT2im5wV1YGGDora5vTv/aa5bE=)
	golang.org/x/mod@v0.12.0 (sum: h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc=)
	golang.org/x/sys@v0.11.0 (sum: h1:eG7RXZHdqOJ1i+0lgLgCpSXAp6M3LYlAo6osgSi0xOM=)
	golang.org/x/tools@v0.12.1-0.20230825192346-2191a27a6dc5 (sum: h1:Vk4mysSz+GqQK2eqgWbo4zEO89wkeAjJiFIr9bpqa8k=)

Panic is identical to what @tomasaschan posted.

@tomasaschan
Copy link

I was able to fix my setup by reinstalling go 1.22, after uninstalling go 1.21 (even though the go version reported in my terminal was already 1.22).

My conclusion is that, despite what my terminal reported, the tools were installed using Go 1.21, and when reinstalled with 1.22 it worked.

@fatelei
Copy link

fatelei commented Feb 18, 2024

+1 panic

@muya
Copy link

muya commented Feb 18, 2024 •
edited

I was facing a similar issue with a Homebrew installed version of staticcheck and Go 1.22.0.

Even after reinstalling (brew reinstall staticcheck), staticcheck --debug.version still noted that staticcheck was built with a previous version of Go.

staticcheck 2023.1.6 (v0.4.6)

Compiled with Go version: go1.21.1
Main module:
	honnef.co/go/tools
Dependencies:
	github.com/BurntSushi/toml@v1.2.1 (sum: h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=)
	golang.org/x/exp/typeparams@v0.0.0-20221208152030-732eee02a75a (sum: h1:Jw5wfR+h9mnIYH+OtGT2im5wV1YGGDora5vTv/aa5bE=)
	golang.org/x/mod@v0.12.0 (sum: h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc=)
	golang.org/x/sys@v0.11.0 (sum: h1:eG7RXZHdqOJ1i+0lgLgCpSXAp6M3LYlAo6osgSi0xOM=)
	golang.org/x/tools@v0.12.1-0.20230825192346-2191a27a6dc5 (sum: h1:Vk4mysSz+GqQK2eqgWbo4zEO89wkeAjJiFIr9bpqa8k=)

Resolution

Re-installing with -s / --build-from-source enabled forced it to be re-built with the latest go version, and resolved the issue for me:

brew reinstall -s staticcheck

staticcheck 2023.1.6 (v0.4.6)

Compiled with Go version: go1.22.0
Main module:
	honnef.co/go/tools
Dependencies:
	github.com/BurntSushi/toml@v1.2.1 (sum: h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=)
	golang.org/x/exp/typeparams@v0.0.0-20221208152030-732eee02a75a (sum: h1:Jw5wfR+h9mnIYH+OtGT2im5wV1YGGDora5vTv/aa5bE=)
	golang.org/x/mod@v0.12.0 (sum: h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc=)
	golang.org/x/sys@v0.11.0 (sum: h1:eG7RXZHdqOJ1i+0lgLgCpSXAp6M3LYlAo6osgSi0xOM=)
	golang.org/x/tools@v0.12.1-0.20230825192346-2191a27a6dc5 (sum: h1:Vk4mysSz+GqQK2eqgWbo4zEO89wkeAjJiFIr9bpqa8k=)

mvdan added a commit to mvdan/go-dvote that referenced this issue Feb 19, 2024
@mvdan
CI: build staticcheck release from source
56f480c 
Upstream's latest version works fine when built with Go 1.22,
but their release archives are built with 1.21,
and that seems to trigger a panic due to issue
dominikh/go-tools#1496.

Thankfully, building from source is easy enough.
It shouldn't cause any noticeable slowdown, since we reuse both
the modules and build Go caches via actions/setup-go.
p4u pushed a commit to vocdoni/vocdoni-node that referenced this issue Feb 21, 2024
@mvdan @p4u
CI: build staticcheck release from source
41c5738 
Upstream's latest version works fine when built with Go 1.22,
but their release archives are built with 1.21,
and that seems to trigger a panic due to issue
dominikh/go-tools#1496.

Thankfully, building from source is easy enough.
It shouldn't cause any noticeable slowdown, since we reuse both
the modules and build Go caches via actions/setup-go.
@nomad-software
Copy link

I'm seeing the same issue.

@dominikh
Copy link
Owner

New release is out.

@Akaame
Copy link

Akaame commented Feb 23, 2024

Tested on both Apple Silicon and Linux amd64

> go version
go version go1.22.0 darwin/arm64

> go install honnef.co/go/tools/cmd/staticcheck@v0.4.7
> staticcheck -debug.version                      
staticcheck 2023.1.7 (v0.4.7)

Compiled with Go version: go1.21.7
Main module:
        honnef.co/go/tools@v0.4.7 (sum: h1:9MDAWxMoSnB6QoSqiVr7P5mtkT9pOc1kSxchzPCnqJs=)
Dependencies:
        github.com/BurntSushi/toml@v1.2.1 (sum: h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=)
        golang.org/x/exp/typeparams@v0.0.0-20221208152030-732eee02a75a (sum: h1:Jw5wfR+h9mnIYH+OtGT2im5wV1YGGDora5vTv/aa5bE=)
        golang.org/x/mod@v0.12.0 (sum: h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc=)
        golang.org/x/sys@v0.11.0 (sum: h1:eG7RXZHdqOJ1i+0lgLgCpSXAp6M3LYlAo6osgSi0xOM=)
        golang.org/x/tools@v0.12.1-0.20230825192346-2191a27a6dc5 (sum: h1:Vk4mysSz+GqQK2eqgWbo4zEO89wkeAjJiFIr9bpqa8k=)
        
> go install honnef.co/go/tools/cmd/staticcheck@master
> staticcheck -debug.version    
staticcheck (devel, v0.5.0-0.dev.0.20240222130255-69fbc046a2b0)

Compiled with Go version: go1.22.0
Main module:
        honnef.co/go/tools@v0.5.0-0.dev.0.20240222130255-69fbc046a2b0 (sum: h1:zATFNFAnrNPHCuwz2b0+axa9pbvnJkezr7Mb3DMkXmM=)
Dependencies:
        github.com/BurntSushi/toml@v1.3.2 (sum: h1:o7IhLm0Msx3BaB+n3Ag7L8EVlByGnpq14C4YWiu/gL8=)
        golang.org/x/exp/typeparams@v0.0.0-20231108232855-2478ac86f678 (sum: h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=)
        golang.org/x/mod@v0.14.0 (sum: h1:dGoOF9QVLYng8IHTm7BAyWqCqSheQ5pYWGhzW00YJr0=)
        golang.org/x/sys@v0.14.0 (sum: h1:Vz7Qs629MkJkGyHxUlRHizWJRG2j8fbQKjELVSNhy7Q=)
        golang.org/x/tools@v0.15.0 (sum: h1:zdAyfUGbYmuVokhzVmghFl2ZJh5QhcfebBgmVPFYA+8=)

What are we doing wrong?

(Should I create a new issue for this?)

@dominikh
Copy link
Owner

I have absolutely no idea how that would be possible.

@maersu
Copy link

maersu commented Feb 28, 2024 •
edited

Same here on Apple M1, with 1.22.0 and v0.4.7

staticcheck ./...            
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x1310712]

I deleted go rm -rf /usr/local/go and rm /etc/paths.d/go and installed go 1.22.0 again and latest staticcheck go install honnef.co/go/tools/cmd/staticcheck@latest

and now it works, no idea what changed ... but thanks to tomasaschan

@Akaame Akaame mentioned this issue Feb 28, 2024
Closed
singholt added a commit to singholt/amazon-ecs-agent that referenced this issue May 21, 2024
@singholt
make get-deps-stamp: install staticcheck@2023.1.6
647dc4c 
see dominikh/go-tools#1496
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests