x/tools/gopls: DidChangeWatchedFiles: impossible crash in growslice

[adonovan]

#!stacks
"sigpanic" && "growslice:+17"

Issue created by stacks.

Another impossible crash: the compiler generates code to load the *Snapshot type descriptor from rodata in R4, then calls growslice, which experiences a SEGV while loading from this register at L194.

golang.org/x/tools/gopls/internal/cache.(*Session).ExpandModificationsToDirectories STEXT size=1504 args=0x30 locals=0x318 funcid=0x0 align=0x0
...
	0x019c 00412 	L0967	MOVD	$type:*golang.org/x/tools/gopls/internal/cache.Snapshot(SB), R4
	0x01a4 00420 	L0967	CALL	runtime.growslice(SB)
...
runtime.growslice STEXT size=1536 args=0x28 locals=0x58 funcid=0x0 align=0x0
	0x0000 00000 	L0177	MOVD	16(g), R16
	0x0004 00004 	L0177	CMP	R16, RSP
	0x0008 00008 	L0177	BLS	1500
	0x000c 00012 	L0177	MOVD.W	R30, -96(RSP)
	0x0010 00016 	L0177	MOVD	R29, -8(RSP)
	0x0014 00020 	L0177	SUB	$8, RSP, R29
	0x0018 00024 	L0178	SUB	R3, R1, R3
	0x001c 00028 	L0190	TBNZ	$63, R1, 1476
	0x0020 00032 	L0194	MOVD	(R4), R5                        <----- SEGV

Unlike all previous crashes, which have been loads from SP or g, this one is an ordinary register. I'm struggling to think of a realistic scenario in which an application bug (e.g. data race, misuse of unsafe) could cause this problem. It's one thing for buggy code to clobber arbitrary memory, but this crash means that a register has been corrupted. R4 has somehow been clobbered between the load from rodata (which can't have been written) and the load at L194, with no intervening function calls. I suppose it's possible that the runtime suspended the g in between, and the memory where the g's register file was saved was corrupted, but that seems very unlikely, not least because there is nothing that would synchronously invoke the scheduler in this handful of instructions.

I'm starting to suspect that this is a bug not in the application, but in the runtime or hardware. @prattmic

This stack fcv6BQ was reported by telemetry:

• crash/crash
• runtime.throw:+9,+0x37
• runtime.sigpanic:+33,+0x223
• runtime.growslice:+17,+0x20
• golang.org/x/tools/gopls/internal/cache.(*Session).ExpandModificationsToDirectories:+9,+0x17f
• golang.org/x/tools/gopls/internal/server.(*server).didModifyFiles:+34,+0x2eb
• golang.org/x/tools/gopls/internal/server.(*server).DidChangeWatchedFiles:+13,+0x1fb
• golang.org/x/tools/gopls/internal/protocol.serverDispatch:+634,+0x5437
• golang.org/x/tools/gopls/internal/lsprpc.(*StreamServer).ServeStream.ServerHandler.func4:+5,+0x73
• golang.org/x/tools/gopls/internal/lsprpc.(*StreamServer).ServeStream.handshaker.func5:+52,+0x68f
• golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2,+0xbf
• golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3,+0x8f
• runtime.goexit:+0,+0x3

golang.org/x/tools/gopls@v0.20.0 go1.24.4 darwin/arm64 other,vscode (1)

[gabyhelp]

Related Issues

• x/tools/gopls: growslice crashes while zeroing #74932
• x/tools/gopls: sigpanic in methods of persistent.Map (corrupt g) #74870
• x/tools/gopls: automated issue report (crash) #40449 (closed)
• x/tools/gopls: SEGV in HasSuffix (corrupt string) #74348
• x/tools/gopls: automated issue report (crash) #40819 (closed)
• x/tools/gopls: impossible SEGV in regexp/syntax.MatchRunePos #73090
• x/tools/gopls: call to IsGenerated ocassionally has nil Snapshot causing panic #41778 (closed)
• x/tools/gopls: nil deref in 'go vendor' Snapshot.GoCommandInvocation #73891
• gopls: panic #42077 (closed)
• x/tools/gopls: panic because of nil pointer in cache.fileWasSaved #37687 (closed)

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

[prattmic]

there is nothing that would synchronously invoke the scheduler in this handful of instructions

The beginning of this function does have a stack check:

runtime.growslice STEXT size=1536 args=0x28 locals=0x58 funcid=0x0 align=0x0
	0x0000 00000 	L0177	MOVD	16(g), R16
	0x0004 00004 	L0177	CMP	R16, RSP
	0x0008 00008 	L0177	BLS	1500

The BLS 1500 is presumably a jump down to a call to runtime.morestack. This would be used to grow the stack, or do synchronous preemption (morestack handles both). Upon return, morestack would continue execution of the function.

So if preemption corrupted R4, it didn't need to be asynchronous preemption. Still, corruption of an ordinary general purpose register would be a fairly surprising bug.

cc @golang/runtime