runtime: SEGV in mapaccess2 (go1.23.2 darwin/amd64)

[adonovan]

#!stacks
"runtime.sigpanic" && "runtime.mapaccess2:+22"

Issue created by stacks.

The line numbers are again suspicious, possibly an instance of #70885.

This stack zjaBOQ was reported by telemetry:

• crash/crash
• runtime.throw:+9
• runtime.sigpanic:+33
• runtime.interhash:+6
• runtime.mapaccess2:+22
• golang.org/x/tools/internal/gcimporter.(*iexporter).typOff:+1
• golang.org/x/tools/internal/gcimporter.(*exportWriter).typ:+1
• golang.org/x/tools/internal/gcimporter.(*exportWriter).doTyp:+44
• golang.org/x/tools/internal/gcimporter.(*iexporter).typOff:+4
• golang.org/x/tools/internal/gcimporter.(*exportWriter).typ:+1
• golang.org/x/tools/internal/gcimporter.(*exportWriter).param:+3
• golang.org/x/tools/internal/gcimporter.(*exportWriter).paramList:+4
• golang.org/x/tools/internal/gcimporter.(*exportWriter).signature:+1
• golang.org/x/tools/internal/gcimporter.(*iexporter).doDecl:+141
• golang.org/x/tools/internal/gcimporter.iexportCommon:+55
• golang.org/x/tools/internal/gcimporter.IExportShallow:+8
• golang.org/x/tools/gopls/internal/cache.storePackageResults:+9

golang.org/x/tools/[email protected] go1.23.2 darwin/amd64 other (1)

@prattmic

[gabyhelp]

Related Issues

• x/tools/gopls: crash in Hover (telemetry) #69362
• x/tools/gopls: sigpanic in persistent.(*mapNode).forEach #71115
• runtime: SIGSEGV in mapassign_fast64 during cmd/vet #35689 (closed)
• x/tools/gopls: crash exporting constant with partially defined type #60891 (closed)
• x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
• gopls SEGV fault on startup. #70271 (closed)
• x/tools/gopls: OOM reported by fatal in runtime.mallocgc (windows) #70445 (closed)
• cmd/compile: bug in cmd/compile/internal/importer.(*pkgReader).objIdx.func1 #70996
• x/tools/gopls/internal/test/integration/misc: unrecognized failures #65862 (closed)
• runtime: panic issues with go get #16634 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

This is dying trying to hash a non-empty interface.
The itab field of the interface is non-nil, but segv's when dereferenced.
That should be impossible. All non-nil itab fields point to static locations in the binary or persistentalloc'd memory. Both should never segv.

So this looks like general corruption (nothing specifically to do with maps). One possibility is incorrect freeing of the object containing the interface.

I presume we don't have the segv address? If we had that, it might clarify somewhat.

[adonovan]

I presume we don't have the segv address? If we had that, it might clarify somewhat.

Sadly not; all we have to go on is the line numbers in that telemetry link.

[prattmic]

Why do you say the line numbers are suspicious? All the ones I looked at seem reasonable to me.

[adonovan]

Why do you say the line numbers are suspicious? All the ones I looked at seem reasonable to me.

Because a load from a non-nil pointer "cannot fail", so I assumed the real problem was on an adjacent line (remembering our recent telemetry problems), but Keith's comment explains it: general corruption of memory. This is something that happens so rarely in Go that I was reluctant to jump to that conclusion. Also, I've been burned too many times by blaming compiler folks for my own bugs. ;-)

[prattmic]

Usually bad cgo or unsafe code would be a top candidate for memory corruption, but since this is specifically the gopls binary, there should be very little of either.