[aeijdenberg-canva]

Can confirm that #215 is not latent. We see this when using buildkite/agent when built against v1.1.24 in a very small % of builds.

Here is a test showing it (this passes on master, but fails when applied to v1.1.24):

$ go test -run TestOpenUnderGCStackShrink -v .
=== RUN   TestOpenUnderGCStackShrink
    stackmove_linux_test.go:82: 78636 Open() calls under GC pressure, 0 wrong.
--- PASS: TestOpenUnderGCStackShrink (3.00s)
PASS
ok      github.com/creack/pty   (cached)

on v1.1.24:

$ git reset --hard v1.1.24
HEAD is now at edfbf75 Merge pull request #201 from MacMalainey/master
$ git cherry-pick origin/unsafe-pointer-regression-test
[unsafe-pointer-regression-test 2ff2ef0] Add stress test for pointer-to-uintptr ioctl arguments moved by a GC stack shrink
 Date: Mon Sep 7 21:09:50 2026 -0400
 1 file changed, 142 insertions(+)
 create mode 100644 stackmove_linux_test.go
$ go test -run TestOpenUnderGCStackShrink -v .
=== RUN   TestOpenUnderGCStackShrink
    stackmove_linux_test.go:80: master index 10, tty named /dev/pts/0, slave is /dev/pts/0.
    stackmove_linux_test.go:82: 113 Open() calls under GC pressure, 1 wrong.
--- FAIL: TestOpenUnderGCStackShrink (0.00s)
FAIL
FAIL    github.com/creack/pty   0.007s
FAIL

Longer info

Before #215, ptsname/unlockpt/Getsize/Setsize computed uintptr(unsafe.Pointer(&n)) and passed the integer through ioctl to Syscall. The conversion is only safe inside the Syscall argument list (unsafe.Pointer rule 4); done earlier, a GC stack shrink between the conversion and the syscall moves n and the kernel writes TIOCGPTN's result into the old stack. n keeps its zero value, Open() names /dev/pts/0 and opens another pty's slave, and Start's TIOCSCTTY fails with EPERM. Seen in production at ~1 in 25k pty opens; every capture was slave=/dev/pts/0 with a different real index.

v1.1.19 had the same conversion but ioctl was inlined straight into Syscall, so nothing could move the stack in between. v1.1.20 made ioctl call f.Fd() (frames plus an fcntl syscall) after the conversion, which gave the GC somewhere to shrink the stack. Within Open() only a shrink can do it: os.OpenFile has already pushed the high-water mark past ptsname's frames, so growth never lands in the window.

TestOpenUnderGCStackShrink keeps goroutines shrink-eligible while hammering the GC and checks every pair against a TIOCGPTN read done the safe way. It fails within milliseconds on v1.1.20 through v1.1.24 and passes on master.

With thanks to Claude Fable.

[neilcawse]

+1, we hit this in production too: Geotab's gia CLI on Linux, Go 1.27.2, built against v1.1.24. Rarely, Open returns /dev/pts/0 instead of the master's peer. Start with Setsid+Setctty then fails with fork/exec ...: operation not permitted. Otherwise the child gets attached to the wrong terminal.

Our repro is a GC loop plus 16 goroutines × 2000 Open calls, each after a deep call that grows the stack. On v1.1.24 it gives 17–59 wrong slaves per 32,000 opens, and occasionally a runtime fault. With the ioctl pointer kept as unsafe.Pointer until the Syscall call itself (the same approach as #215), it gives 0 across repeated runs, including -race.

@creack, could you tag a release that includes #215? v1.1.24 is still the latest tag, so everyone on a tagged version is exposed. Thanks!