Да, это не опечатка: не рантайм, не race condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare — при 84 миллионах HTTP-запросов в секунду.
На ARM64-машинах Cloudflare стали вылезать странные паники вроде
traceback did not unwind completely — ошибка, указывающая на повреждённый стек при попытке раскрутки. Поначалу инженеры списали это на баг в старом коде с panic/recover, потом — на библиотеку Go Netlink. Но когда даже без неё паники продолжились, стало ясно: проблема глубже.После недель отладки выяснилось: краш происходит при асинхронном вытестении (введённом в Go 1.14), когда рантайм прерывает горутину между двумя машинными инструкциями, корректирующими указатель стека. В этот момент стек оказывается в «разрезанном» состоянии — раскрутчик стека получает некорректный указатель и падает.
Инженеры написали минимальный Go-пример, где функция с большим стеком (>64 КБ) порождает тот самый двойной ADD. После пары минут работы программа стабильно умирала с SIGSEGV. Без сторонних библиотек. Только чистый Go.
package main
import (
"runtime"
)
//go:noinline
func big_stack(val int) int {
var big_buffer = make([]byte, 1 << 16)
sum := 0
// предотвращаем оптимизацию стека компилятором
for i := 0; i < (1<<16); i++ {
big_buffer[i] = byte(val)
}
for i := 0; i < (1<<16); i++ {
sum ^= int(big_buffer[i])
}
return sum
}
func main() {
go func() {
for {
runtime.GC()
}
}()
for {
_ = big_stack(1000)
}
}
Разобравшись, они подтвердили: это ошибка в компиляторе Go, который на ARM64 разбивает корректировку стека на две инструкции, не учитывая возможность асинхронного вытеснения между ними.
Go-команда признала баг и исправила его в версиях go1.23.12, go1.24.6 и go1.25.0.
Получается, даже компиляторы ошибаются) Просто чтобы поймать такой баг, нужно немного — пара сотен дата-центров и десятки миллионов запросов в секунду.
Источник
@go_for_devs