runtime: panic in runtime.mapiterinit (loong64)

[gopherbot]

#!watchflakes
default <- pkg == "golang.org/x/tools/gopls/internal/test/integration/misc" && test == "TestIssue38815/default"

Issue created automatically to collect these failures.

Example (log):

=== RUN   TestIssue38815/default
panic: runtime error: invalid memory address or nil pointer dereference
	panic: invalid handle
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12007eee8]

goroutine 45720 [running]:
golang.org/x/tools/gopls/internal/cache.assert(...)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/debug.go:10
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle.func1()
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:1074 +0x2e8
panic({0x120bd6e40?, 0x12170d4a0?})
	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:785 +0x13c
golang.org/x/tools/gopls/internal/cache/typerefs.(*PackageSet).Union(...)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/typerefs/packageset.go:111
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle(0xc00c63cb00, {0x121038b40, 0xc006aa0960}, 0xc00cdefe00)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:1199 +0xcbc
golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles.func2.1()
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:896 +0xc8
golang.org/x/sync/errgroup.(*Group).Go.func1()
	/home/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:78 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 45718
	/home/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:75 +0xb4

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "golang.org/x/tools/gopls/internal/test/integration/misc" && test == "TestIssue38815/default"

2024-12-11 20:45 x_tools-go1.23-linux-loong64 tools@c1ff179f release-branch.go1.23@69c8cfe2 x/tools/gopls/internal/test/integration/misc.TestIssue38815/default [ABORT] (log)

=== RUN   TestIssue38815/default
panic: runtime error: invalid memory address or nil pointer dereference
	panic: invalid handle
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12007eee8]

goroutine 45720 [running]:
golang.org/x/tools/gopls/internal/cache.assert(...)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/debug.go:10
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle.func1()
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:1074 +0x2e8
panic({0x120bd6e40?, 0x12170d4a0?})
	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:785 +0x13c
golang.org/x/tools/gopls/internal/cache/typerefs.(*PackageSet).Union(...)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/typerefs/packageset.go:111
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle(0xc00c63cb00, {0x121038b40, 0xc006aa0960}, 0xc00cdefe00)
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:1199 +0xcbc
golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles.func2.1()
	/home/swarming/.swarming/w/ir/x/w/targetrepo40136824/gopls/internal/cache/check.go:896 +0xc8
golang.org/x/sync/errgroup.(*Group).Go.func1()
	/home/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:78 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 45718
	/home/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:75 +0xb4

— watchflakes

[findleyr]

I don't understand this at all. The panic is as noted below:

func (s *PackageSet) Union(other *PackageSet) {
	if other == nil {
		return // e.g. unsafe
	}
	if other.parent != s.parent {
		panic("other set is from a different PackageIndex instance")
	}
	for k, v := range other.sparse { // <-- panic here
		if v0 := s.sparse[k]; v0 != v {
			s.sparse[k] = v0 | v
		}
	}
}

Other is a non-nil local variable. I'm also not seeing any obvious data race, though I will look more tomorrow.

[adonovan]

The only fallible operation on that line is the other pointer dereference, but obviously that pointer is non-nil. Very odd.

[adonovan]

Building the exact executable, it looks like the location represents a CALL runtime.mapiterinit operation from this line of Union, as inlined into evaluatePackageHandle . I think this is likely a loong-specific bug either in code generation or in the runtime.

$ git co c1ff179f1
$ (cd gopls && GOWORK=off GOTOOLCHAIN=go1.23.4 GOOS=linux GOARCH=loong64 go test -c -o x ./internal/test/integration/misc)
$ go tool objdump ./gopls/x 
...
TEXT golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle(SB) /Users/adonovan/w/xtools/gopls/internal/cache/check.go
 ...
  packageset.go:111	0x8bcd60		28c020e5		MOVV 8(R7), R5											
  packageset.go:111	0x8bcd64		02ca8074		ADDV $672, R3, R20										
  packageset.go:111	0x8bcd68		55b50bdf		CALL -2134718(PC)										
  packageset.go:111	0x8bcd6c		1a006324		PCALAU12I $793, R4										
  packageset.go:111	0x8bcd70		02cc0084		ADDV $768, R4											
  packageset.go:111	0x8bcd74		02ca8066		ADDV $672, R3, R6										
  packageset.go:111	0x8bcd78		54d83bdf		CALL runtime.mapiterinit(SB)
(+0xcbc is here)
  packageset.go:111	0x8bcd7c		50000c00		JMP 3(PC)				 						
  packageset.go:111	0x8bcd80		02ca8064		ADDV $672, R3, R4										
  packageset.go:111	0x8bcd84		54da7fdf		CALL runtime.mapiternext(SB)									
  packageset.go:111	0x8bcd88		28ca8067		MOVV 672(R3), R7										
  packageset.go:111	0x8bcd8c		43ffa4ff		BEQ R7, -23(PC)											
  packageset.go:111	0x8bcd90		28c000e6		MOVV 0(R7), R6											
  packageset.go:111	0x8bcd94		29c3a066		MOVV R6, 232(R3)										
  packageset.go:111	0x8bcd98		28caa067		MOVV 680(R3), R7										
  packageset.go:111	0x8bcd9c		28c000e7		MOVV 0(R7), R7											
  packageset.go:111	0x8bcda0		29c34067		MOVV R7, 208(R3)										
...
										

[findleyr]

CC @golang/loong64

I still have yet to convince myself this is unrelated to a data race -- the locking around the operation is unfortunately tricky. If folks maintaining the loong64 port have any insight, it would be appreciated.

[adonovan]

This stack unfortunately provides nothing to go on about what happened (and where) in runtime.mapiterinit: everything above the "Union" line (panic, defer, SIGSEGV) is related to the handling of the panic and the secondary panic it caused, not the root cause. The Iter.Init function looks completely safe; but I can well imagine Iter.Next is sensitive to data races, its attempt to detect them notwithstanding.

[abner-chenc]

CC @golang/loong64

I still have yet to convince myself this is unrelated to a data race -- the locking around the operation is unfortunately tricky. If folks maintaining the loong64 port have any insight, it would be appreciated.

Sorry，I am carefully checking the code of loong64. and I've also stumbled upon race-related issues while testing on loong64 machine.

[findleyr]

@abner-chenc are your issues related specifically to gopls, or another program?

[findleyr]

Unless there is further evidence that this is related to a data race in gopls, I will operate under the assumption that this is a loong64 issue. Removing the gopls label to get this off our triage dashboard: please add the label back if there is additional information implicating gopls.