Package: src:golang-1.27 Version: 1.27.2-1 Severity: serious Tags: ftbfs Control: affects -1 + src:siso X-Debbugs-Cc: [email protected], [email protected]
Hi found this issue through * Build log: https://buildd.debian.org/status/fetch.php?pkg=siso&arch=ppc64el&ver=1.6.4%2Bds-1&stamp=1792241113&file=log I did some tests, and found that Go programs built for ppc64el with -buildmode=pie die at startup with golang-1.27. The same source built without -buildmode=pie runs fine, and golang-1.26 was fine, so this is a 1.27 regression. It makes siso FTBFS on ppc64el, because debian/rules runs the binary it just built to generate the man page. Smallest case I found: package main import ( "fmt" "os" "golang.org/x/sys/unix" ) func main() { _, _ = unix.IoctlGetTermios(int(os.Stdout.Fd()), unix.TCGETS) fmt.Println("ok") } GOARCH=ppc64le CGO_ENABLED=0 go build -buildmode=pie -o r . Under qemu-ppc64le that binary never returns and sits at 100% CPU. Without -buildmode=pie it prints ok. SIGQUIT on the wedged process gives a stack the runtime itself rejects: runtime: g 1: unexpected return pc for sync.(*Pool).pinSlow called from 0x1001b8890 siso fails earlier and harder, on the first sampled allocation in a package init: runtime.mProf_Malloc runtime/mprof.go:443 runtime.panicBounds runtime/asm_ppc64x.s:1410 runtime.findfunc runtime/symtab.go:923 runtime.findmoduledatap runtime/symtab.go:866 <- SIGSEGV siso/ui.init.0 ui/ui.go:82 mprof.go:443 is mp.profStack[:debug.profstackdepth+2], and profStack is allocated as 1+maxSkip+profstackdepth (proc.go:1076), so the bound is 130 against a length of 135: that check cannot legitimately fire. The SIGSEGV afterwards is at a different address in each build, 0x2a0 then 0x0, which looks like a garbage pointer rather than a nil one. Both faults are reads of runtime globals early in startup, and on ppc64 a PIE binary reaches globals through the TOC in r2. buildd history is at https://buildd.debian.org/status/logs.php?pkg=siso&arch=ppc64el : 1.6.4+ds-1 Maybe-Failed three times, while 1.5.13+ds-1 through 1.5.22+ds-2 all succeeded under golang-1.26. I reproduced it in a clean sid ppc64el chroot under qemu-user, so it is not hardware specific. I checked for duplicates today and found none: no ppc64el bug against golang-1.27, nothing matching in the Go tracker. The closest precedents are https://github.com/golang/go/issues/30283, Best, Juan
