Internal panic in pointer analysis

[ondrajz]

Internal panic in pointer analysis

[ondrajz]

Hey, thanks for reporting this issue.

It seems like this is a bug in the pointer analysis package that go-callvis uses: github.com/golang.org/x/tools/go/pointer.

I found similar issue from someone in 2014: https://groups.google.com/forum/#!msg/golang-dev/G-Yc8908DBw/x9DTgrrtlDYJ

I tried running pointer analysis with callgraph tool and same panic occurred:

➤ callgraph -algo=pta -format graphviz github.com/lightningnetwork/lnd
Internal panic in pointer analysis:
goroutine 1 [running]:
runtime/debug.Stack(0x24, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x22
golang.org/x/tools/go/pointer.Analyze.func1(0xc47133dc48)
	/home/furby/go/src/golang.org/x/tools/go/pointer/analysis.go:227 +0x110
panic(0x68bce0, 0xc44fe99c80)
	/usr/local/go/src/runtime/panic.go:502 +0x229
golang.org/x/tools/go/pointer.(*analysis).taggedValue(0xc42ab28700, 0xc4000331aa, 0x1, 0x64, 0xc426000000)
	/home/furby/go/src/golang.org/x/tools/go/pointer/gen.go:272 +0x13a
golang.org/x/tools/go/pointer.(*untagConstraint).solve(0xc42ddf4640, 0xc42ab28700, 0xc426fb9cc0)
	/home/furby/go/src/golang.org/x/tools/go/pointer/solve.go:295 +0xd2
golang.org/x/tools/go/pointer.(*analysis).solveConstraints(0xc42ab28700, 0xc44a600090, 0xc426fb9cc0)
	/home/furby/go/src/golang.org/x/tools/go/pointer/solve.go:165 +0xa9
golang.org/x/tools/go/pointer.(*analysis).solve(0xc42ab28700)
	/home/furby/go/src/golang.org/x/tools/go/pointer/solve.go:59 +0x2fb
golang.org/x/tools/go/pointer.Analyze(0xc42ce4ca00, 0x0, 0x735380, 0xc44fe99ca0)
	/home/furby/go/src/golang.org/x/tools/go/pointer/analysis.go:331 +0x51d
main.doCallgraph(0x880be0, 0x7ffce4a89798, 0x3, 0x7ffce4a897a4, 0x8, 0x0, 0xc4200a4130, 0x1, 0x1, 0x0, ...)
	/home/furby/go/src/golang.org/x/tools/cmd/callgraph/main.go:233 +0x2cc
main.main()
	/home/furby/go/src/golang.org/x/tools/cmd/callgraph/main.go:161 +0x96
callgraph: internal error in pointer analysis: not a tagged object: n209322 (please report this bug)

I will report this upstream to find out what's wrong.

EDIT: reported: https://groups.google.com/forum/#!topic/golang-dev/mtO8T5FKRuM

[Dieterbe]

Not sure if you need more examples, but got another one, while analyzing the current master of github.com/grafana/metrictank

go-callvis -nostd -focus api github.com/grafana/metrictank/cmd/metrictank                                                                                           ⏎
Internal panic in pointer analysis:
goroutine 1 [running]:
runtime/debug.Stack(0x24, 0x0, 0x0)
	/usr/lib/go/src/runtime/debug/stack.go:24 +0xa7
runtime/debug.PrintStack()
	/usr/lib/go/src/runtime/debug/stack.go:16 +0x22
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze.func1(0xc07779bce0)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:227 +0x10b
panic(0x8634a0, 0xc0374800c0)
	/usr/lib/go/src/runtime/panic.go:513 +0x1b9
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*analysis).taggedValue(0xc0145b7340, 0xc000023913, 0x4, 0x64, 0xc0068dc700)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/gen.go:272 +0x12a
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*untagConstraint).solve(0xc02f5945a0, 0xc0145b7340, 0xc0155346c0)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/solve.go:295 +0xeb
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*analysis).solveConstraints(0xc0145b7340, 0xc02f59dce0, 0xc0155346c0)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/solve.go:165 +0x170
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*analysis).solve(0xc0145b7340)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/solve.go:59 +0x2e0
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze(0xc006103810, 0x0, 0x99b3a0, 0xc0374800f0)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:331 +0x4ce
main.doAnalysis(0xcd4080, 0x0, 0xc0000b0040, 0x1, 0x1)
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/analysis.go:71 +0x6ce
main.main()
	/home/dieter/go/src/github.com/TrueFurby/go-callvis/main.go:107 +0x108
2019/01/17 10:09:13 analyze failed: internal error in pointer analysis: not a tagged object: n145683 (please report this bug)

[florianeichin]

I got the same trying to visualize Buildkit

florian@florian-VirtualBox:~/go/src/github.com/TrueFurby/go-callvis$ go-callvis -limit github.com/moby/buildkit -ignore github.com/moby/buildkit/vendor github.com/moby/buildkit/cmd/buildctl | dot -Tpng -o buildkit.png
Internal panic in pointer analysis:
goroutine 1 [running]:
runtime/debug.Stack(0x24, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze.func1(0xc444423a88)
	/home/florian/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:227 +0x110
panic(0x686920, 0xc44d772ae0)
	/usr/local/go/src/runtime/panic.go:502 +0x229
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*analysis).callEdge(0xc4318f8fc0, 0xc43ee2b5f0, 0xc4254b0560, 0xce2b)
	/home/florian/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:368 +0x7cc
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze(0xc43eea00a0, 0x0, 0x72e7e0, 0xc44d772af0)
	/home/florian/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:354 +0x6fd
main.run(0x884be0, 0x6f545c, 0x4, 0xc444423eb0, 0xc42006a7f0, 0x1, 0x1, 0xc42006a810, 0x1, 0x1, ...)
	/home/florian/go/src/github.com/TrueFurby/go-callvis/main.go:159 +0x720
main.main()
	/home/florian/go/src/github.com/TrueFurby/go-callvis/main.go:77 +0x758
go-callvis: internal error in pointer analysis: callEdge dynamic function call -> n52779: not a function object (please report this bug)

[gurre]

Similar here
analyze failed: internal error in pointer analysis: callEdge dynamic function call -> n66773: not a function object (please report this bug)

[cybertramp]

Similar here too..it is not working...
./go-callvis github.com/docker/cli/cmd/docker

Internal panic in pointer analysis:
goroutine 1 [running]:
runtime/debug.Stack(0x24, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze.func1(0xc0a7ebfce0)
	/home/son/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:227 +0x10b
panic(0x862480, 0xc0662a7d60)
	/usr/local/go/src/runtime/panic.go:513 +0x1b9
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.(*analysis).callEdge(0xc05194e700, 0xc00d50f8f0, 0xc0294c0440, 0x535af)
	/home/son/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:368 +0x788
github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer.Analyze(0xc04eca22d0, 0x0, 0x99a2e0, 0xc0662a7e30)
	/home/son/go/src/github.com/TrueFurby/go-callvis/vendor/golang.org/x/tools/go/pointer/analysis.go:354 +0x6b2
main.doAnalysis(0xcd3060, 0x0, 0xc0000a8060, 0x1, 0x1)
	/home/son/go/src/github.com/TrueFurby/go-callvis/analysis.go:71 +0x6ce
main.main()
	/home/son/go/src/github.com/TrueFurby/go-callvis/main.go:80 +0x108
2019/01/13 09:40:03 analyze failed: internal error in pointer analysis: callEdge dynamic function call -> n341423: not a function object (please report this bug)

[ondrajz]

The actual bug is in the golang.org/x/tools/go/pointer package. There already is issue for this, please report your findings here: golang/go#25090

[3cham]

It seems the original issue won't be solved. Could we prevent this by suggesting -ignore option for the caused package?

[ondrajz]

It seems the original issue won't be solved. Could we prevent this by suggesting -ignore option for the caused package?

Unfortunately, ignore is applied after the callgraph analysis.