runtime: Go 1.27.0: SIGSEGV crash with generic function + pointer type parameter + embedded interface

[gospider001]

Go version

go version go1.27.0 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN='/Users/zhaoxiaoxiao/go/bin'
GOCACHE='/Users/zhaoxiaoxiao/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/zhaoxiaoxiao/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/ck/x440zyk97ss3lvz6vqw506tr0000gn/T/go-build3868367583=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/Users/zhaoxiaoxiao/go/pkg/mod'
GOOS='darwin'
GOPACKAGESDRIVER=''
GOPATH='/Users/zhaoxiaoxiao/go'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/zhaoxiaoxiao/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.27.0'
PKG_CONFIG='pkg-config'

What did you do?

Minimal reproduction code

package main

import "log"

type Conn interface{ Hello() }
type PoolConn struct{ Conn } // embedded interface
type CustomConn struct{}

func (p CustomConn) Hello() { log.Print("Hello") }

func call[T Conn](c T) { c.Hello() }

func main() {
	// Crash: generic + pointer type parameter + embedded interface
	call[*PoolConn](&PoolConn{Conn: CustomConn{}})
}

Expected behavior

The program should print Hello normally (consistent with the two working variants below).

Actual behavior

The program crashes directly with the following output:

unexpected fault address 0x100011df0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x2 addr=0x100011df0 pc=0x100011df0]

goroutine 1 gp=0xeb2a8761e0 m=0 mp=0x100405660 [running]:
runtime.throw({0x100346741?, 0x1003461bc?})
        /usr/local/go/src/runtime/panic.go:1243 +0x38 fp=0xeb2a916df0 sp=0xeb2a916dc0 pc=0x10032ae58
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:945 +0x20c fp=0xeb2a916e50 sp=0xeb2a916df0 pc=0x10032c18c
main.main()
        /tmp/mini2.go:16 +0x54 fp=0xeb2a916ea0 sp=0xeb2a916e60 pc=0x1003461e4
runtime.main()
        /usr/local/go/src/runtime/proc.go:302 +0x380 fp=0xeb2a916fd0 sp=0xeb2a916ea0 pc=0x1002faea0
runtime.goexit({})
        /usr/local/go/src/runtime/asm_arm64.s:1039 +0x4 fp=0xeb2a916fd0 sp=0xeb2a916fd0 pc=0x100330514
...
exit status 2

Comparison tests

1. Non-generic direct call (works ✅)

func main() {
	var c *PoolConn = &PoolConn{Conn: CustomConn{}}
	c.Hello() // prints: Hello
}

2. Generic + value type parameter (works ✅)

func main() {
	call[PoolConn](PoolConn{Conn: CustomConn{}}) // prints: Hello
}

3. Generic + pointer type parameter (crashes ❌)

func main() {
	call[*PoolConn](&PoolConn{Conn: CustomConn{}}) // SIGSEGV crash
}

Additional findings

1. go vet reports no warnings — the issue cannot be detected statically.
2. go run -gcflags=-d=checkptr=2 also fails to detect it and still crashes.
3. The crash address 0x100011df0 equals pc=0x100011df0, meaning the program jumped to an invalid/unmapped address (a typical bad itab or function pointer issue).
4. In the original code, if the value-type variant is called first and then the pointer-type variant, the program works — suggesting the bug is related to the order/caching of generic instantiation. It looks like the compiler mishandles the itab of the embedded interface when generating the generic instantiation for *PoolConn.

Original code (real-world scenario)

package main

import (
	"log"
)

type Conn interface{ Hello() }
type Pool[T Conn] struct{}

func (p *Pool[T]) Hello(conn T) { conn.Hello() }

type PoolConn struct{ Conn }
type CustomConn struct{}

func (p CustomConn) Hello() { log.Print("Hello") }

func NewPool[T Conn]() *Pool[T] { return &Pool[T]{} }

func main() {
	// Commenting out this line makes the next line crash; keeping both lines works
	NewPool[PoolConn]().Hello(PoolConn{Conn: CustomConn{}})
	NewPool[*PoolConn]().Hello(&PoolConn{Conn: CustomConn{}})
}

Impact

• Any code using generic + pointer type parameter + embedded interface may trigger this.
• The crash is runtime-only and cannot be caught at compile time; go vet doesn't detect it either.
• This pattern is common in real projects (e.g. a connection pool Pool[T] managing connection objects implementing an interface), so the risk is high.

Suggestions

• Expect the Go team to confirm this is a compiler/runtime bug (likely an error in handling the embedded interface's method table during generic instantiation).
• Temporary workaround: use value type parameters, or avoid the combination of pointer type parameters + embedded interfaces in generics.

What did you see happen?

The program should print Hello normally

What did you expect to see?

The program should print Hello normally

[gospider001]

I only upgraded Go from 1.26.1 to 1.27.0, everything else remained unchanged, and my old code stopped working.

[gabyhelp]

Related Issues

• runtime: function-scoped generic types with the same name and parameters are treated as the same in interface, causing segfault #62134 (closed)
• runtime: SIGBUS in initItab (write to readonly ITab.Fun) on unchecked type assertion with generics #65962 (closed)
• go1.18 beta: Undefined behaviour when using generics in specific circumstances #50621 (closed)
• cmd/compile: compiler panic with generics across packages and pointer type parameter #51367 (closed)
• cmd/compile: nil pointer dereference in the 1.18 compiler when dealing with generic types #50423 (closed)
• cmd/compile: panic when using typeparams #46353 (closed)
• reflect: memory unsafety due to interface shadowing in reflect #80332 (closed)
• x/tools/go/callgraph/rta: nil *ssa.Function on worklist crashes Analyze on exported generic methods #80973
• cmd/compile: devirtualization causes incorrect runtime panic on promoted method of value-embedded generic struct #78404 (closed)
• Using function-local generic types of the same name produces a SIGSEGV #57158 (closed)

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

[DanielMorsing]

Looks like this is a bug in the linker deadcode pass. Bisected it down to this change

[thepudds]

FWIW, on linux/amd64, it reports a more helpful fatal error: unreachable method called. linker bug? from runtime.unreachableMethod (rather than the SEGV reported on darwin/arm64 in the original report):

go/src/runtime/iface.go

Lines 725 to 730 in efef5f0

	// The linker redirects a reference of a method that it determined
	// unreachable to a reference to this function, so it will throw if
	// ever called.
	func unreachableMethod() {
	throw("unreachable method called. linker bug?")
	}

It could be a linker bug, or it could be something like the compiler removing the last reference to a type when it should not (and then the itab being pruned when it should not be, leading to calling unreachableMethod at execution time), or some other compile-side bug something like that.

CC @randall77 for https://go.dev/cl/751465

[cagedmantis]

@golang/compiler

[cuonglm]

@gopherbot Please backport this issue to go1.27, this is a regression that may cause valid program to panic at runtime.

[gopherbot]

Backport issue(s) opened: #81353 (for 1.27).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/827624 mentions this issue: cmd/compile: correctly mark interface calls as used for tail call wrappers