cmd/compile: &(*input) causes segfault

[raphaelvigee]

Go version

go version go1.23.4 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/me/Library/Caches/go-build'
GOENV='/Users/me/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/me/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/me/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.4'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/me/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/me/Documents/Code/project/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/p2/z4h94_g1745dxgtn7h72kjfr0000gn/T/go-build1265390623=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

package main

import (
	"slices"
	"sync"
)

type Child struct {
	Err error
	Something string
	Toy *Toy
	N int
}

type Toy struct {}

type Person struct {
	Children []Child
}

func clone(input *Person) *Person {
    // This variant causes the bug:
	//p := &(*input)
	//pp := p
    // This variant doesnt:
	p := *input
	pp := &p

	p.Children = slices.Clone(p.Children)

	for i, child := range p.Children {
		p.Children[i].Toy = &(*child.Toy)
	}

	return pp
}

func main() {
	p := &Person{Children: []Child{
		{N: 1, Toy: &Toy{}},
		{N: 2, Toy: &Toy{}},
		{N: 3, Toy: &Toy{}},
		{N: 4, Toy: &Toy{}},
		{N: 5, Toy: &Toy{}},
		{N: 6, Toy: &Toy{}},
	}}

	ch := make(chan struct{})

	var wg sync.WaitGroup
	for range 100000 {
		wg.Add(1)

		go func() {
			defer wg.Done()
			<-ch

			p := clone(p)

			p.Children = slices.DeleteFunc(p.Children, func(child Child) bool {
				return child.N %2 == 0
			})
		}()
	}

	close(ch)

	wg.Wait()
}

What did you see happen?

&(*input) caused segfault on p.Children[i].Toy = &(*child.Toy)

What did you expect to see?

*input and separate & doesnt

[gabyhelp]

Related Issues

• maps: segmentation violation in maps.Clone #69110 (closed)
• bug: look like to watch same address when assign to another variable from sub-slice. #56617 (closed)
• making a copy of struct and taking address of it returns pointer to the same struct #59341 (closed)
• cmd/compile: SIGSEGV in noder.checkFetchBody #49246 (closed)
• unexpected panic when struct fields comparison with sync.WaitGroup misuse #36490 (closed)
• maps: segfault in Clone #62203 (closed)

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

[raphaelvigee]

I m wondering if i uncovered a compiler bug of if i'm missing something about pointers dereferencing

[Jorropo]

I can't reproduce the crash.
The compiled output looks correct at first glance, p := &(*input) is a "no-op"* because * produce a value with the argument's pointer underlying addressability and & creates a pointer using the argument's value addressability.

*it is equivalent to if input == nil { panicNilDeref() } which is what it is compiled as

---

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[raphaelvigee]

I can reproduce it ~90% of the time (did you make sure to switch my sample code into "broken mode" ?)

I'm wondering, how is &(*input) different from this ?

p := *input
pp := &p

[ns-dkoblas]

Looking at the non-optimized output I see that there is a substantial different is what is done (e.g. the call to newobject). So I would make the assumption that in the reference to the underlying slice is being shared and thus being corrupted.

For the statement p := &(*input) -- failing case

  example.go:22		0x8b0a			f940bfe5		MOVD 376(RSP), R5	
  example.go:22		0x8b0e			398000bb		MOVB (R5), R27		
  example.go:22		0x8b12			f90053e5		MOVD R5, 160(RSP)	

While the program successfully runs when p := *input with the following assembly

  example.go:22		0x8ba5			90000000		ADRP 0(PC), R0		[0:8]R_ADDRARM64:type:main.Person	
  example.go:22		0x8ba9			91000000		ADD $0, R0, R0		
  example.go:22		0x8bad			94000000		CALL 0(PC)		[0:4]R_CALLARM64:runtime.newobject<1>	
  example.go:22		0x8bb1			f900b3e0		MOVD R0, 352(RSP)	
  example.go:22		0x8bb5			f940bfe1		MOVD 376(RSP), R1	
  example.go:22		0x8bb9			3980003b		MOVB (R1), R27		
  example.go:22		0x8bbd			f9400022		MOVD (R1), R2		
  example.go:22		0x8bc1			f9400423		MOVD 8(R1), R3		
  example.go:22		0x8bc5			f9400821		MOVD 16(R1), R1		
  example.go:22		0x8bc9			f9000403		MOVD R3, 8(R0)		
  example.go:22		0x8bcd			f9000801		MOVD R1, 16(R0)		
  example.go:22		0x8bd1			9000001b		ADRP 0(PC), R27		[0:8]R_ARM64_PCREL_LDST32:runtime.writeBarrier	
  example.go:22		0x8bd5			b9400361		MOVWU (R27), R1		
  example.go:22		0x8bd9			34000041		CBZW R1, 2(PC)		
  example.go:22		0x8bdd			14000002		JMP 2(PC)		
  example.go:22		0x8be1			14000006		JMP 6(PC)		
  example.go:22		0x8be5			94000000		CALL 0(PC)		[0:4]R_CALLARM64:runtime.gcWriteBarrier2	
  example.go:22		0x8be9			f9000322		MOVD R2, (R25)		
  example.go:22		0x8bed			f9400005		MOVD (R0), R5		
  example.go:22		0x8bf1			f9000725		MOVD R5, 8(R25)		
  example.go:22		0x8bf5			14000001		JMP 1(PC)		
  example.go:22		0x8bf9			f9000002		MOVD R2, (R0)		

[Jorropo]

I've tried running both, I'm on linux/amd64.v3 I've missed you are on arm64.
I'll post your test to the build cluster, looking at your tests even if your clone function doesn't do what you think it should do I don't see why it should panic either.

I'm wondering, how is &(*input) different from this ?

In go the * unary operator does not makes a copy, it creates a value using the underlying addressability of the pointer argument.
& also does not make a copy and it uses the underlying addressability of the value.
Among other things this makes & usable to grab pointers to fields or indexes even tho there is implicit pointer deref on [] and ..
Tl;Dr: * converts a pointer to a value without a copy, to make a copy you need to pass that value into anything else (a function, most operators like +, an := or =, ...)

[gopherbot]

Change https://go.dev/cl/638856 mentions this issue: test: add test for 71056

[raphaelvigee]

Thanks for your explanation.
So &(*var) is effectively a noop, i m wondering why so many cases seem to use that pattern ? Are there situations where it makes sense to do that ?

[Jorropo]

I am as puzzled as you are. It's not a no-op because it'll panic if passed a nil pointer but I doubt this is what all of the results in your codesearch intended.

[gopherbot]

Change https://go.dev/cl/639195 mentions this issue: test: add test for 71056

[Jorropo]

Can you please try with go1.24.0-rc1 release ? CI succeeded when tested on today's master.