Repository navigation
x/tools/gopls: idle goroutine crashes in pthread_cond_wait [darwin] #81103
Description
#!stacks
"crash/crash" && "mPark" && "notesleep" && "semasleep" && "runtime.pthread_cond_wait:+1"
Issue created by stacks.
TEXT runtime.pthread_cond_wait.abi0(SB) /var/folders/fy/dn6v01n16zjdwsqy_8qfbbxr000_9w/T/tmp.1KRwczq5uq/go/pkg/mod/golang.org/toolchain
@v0.0.1-go1.26.4.darwin-arm64/src/runtime/sys_darwin.go
sys_darwin.go:487 0x10006d210 f81d0ffe MOVD.W R30, -48(RSP)
sys_darwin.go:487 0x10006d214 f81f83fd MOVD R29, -8(RSP)
sys_darwin.go:487 0x10006d218 d10023fd SUB $8, RSP, R29
sys_darwin.go:487 0x10006d21c b9004bff MOVW ZR, 72(RSP)
sys_darwin.go:488 0x10006d220 f00000e0 ADRP 126976(PC), R0
sys_darwin.go:488 0x10006d224 91010000 ADD $64, R0, R0
sys_darwin.go:488 0x10006d228 9100e3e1 ADD $56, RSP, R1
sys_darwin.go:488 0x10006d22c 94000099 CALL runtime.libcCall(SB) <--- here? (PC points at last byte of CALL)
sys_darwin.go:489 0x10006d230 f9401fe2 MOVD 56(RSP), R2
...
This stack flnhRA was reported by telemetry:
crash/crashruntime.pthread_cond_wait:+1,+0x1fruntime.semasleep:+32,+0x7fruntime.notesleep:+16,+0xabruntime.mPark:=1967,+0x83runtime.stopm:+16,+0x7cruntime.exitsyscallNoP:+47,+0x2f3runtime.mcall:+25,+0x53
golang.org/x/tools/gopls@v0.23.0 go1.26.4 darwin/arm64 gopls.client=claude,vscode (1)
Use this command to reproduce the executable:
(HOME=$(mktemp -d); GOOS=darwin GOARCH=arm64 GOTOOLCHAIN=go1.26.4 go install golang.org/x/tools/gopls@v0.23.0 && find $HOME/go/bin -type f)
To disassemble: go tool objdump exe | less
Activity
adonovan commentedon Aug 25, 2026
@prattmic more random memory corruption, I assume, but the misaligned PC value is a bit odd.
prattmic commentedon Aug 25, 2026
I'm not sure if it translates to telemetry crash collection, but usually when I see stacks like this it's not because that thread actually crashed. Instead, the process was sent a process-wide signal (like SIGABRT), and this just happens to be the thread that the kernel chose to deliver to.
prattmic commentedon Aug 25, 2026
The PC was probably the return instruction (next instruction). Go's traceback subtracts 1 from PCs in various cases to make sure it points into the CALL instead of the return PC.
adonovan commentedon Aug 25, 2026
Ah, good to know. So this is a continuous shotgun of noise even on perfectly working hardware.