OpenAI corrige condição de corrida GNU libunwind de 18 anos via debug 'epidemiológico'

Engenheiros da OpenAI debuggaram e corrigiram uma condição de corrida de 18 anos na função _Ux86_64_setcontext do GNU libunwind que estava causando crashes misteriosus em Rockset, o serviço de infraestrutura de dados C++ alimentando os plugins de busca e dados do ChatGPT. O breakthrough veio não de analisar casos de crash individuais—que apresentavam sintomas contraditórios—mas de aplicar 'debugging epidemiológico': construir um pipeline para analisar automaticamente cada core dump de produção do ano passado, então buscar padrões no nível de população. O time teve ChatGPT escrever um script que extraiu registros de cada core file, filtrou falsos positivos conhecidos e rotulou crashes como return-to-null, misaligned-stack ou outro, rodando em paralelo em um ano de dumps Rockset.

O que parecia ser um bug se mostrou ser dois: corrupção de hardware (um único host físico Azure produzindo silenciosamente resultados incorretos de CPU) e uma genuína condição de corrida libunwind. A causa raíz em libunwind: durante unwinding de exceção C++, a função atualiza o stack pointer (%rsp) antes de terminar a leitura do instruction pointer do struct no stack antigo. Se um sinal chegar naquela janela de picossegundo—aproximadamente 100 picossegundos em velocidades de clock modernas—o kernel constrói seu signal frame no topo do struct, corrompendo o instruction pointer. Rockset da OpenAI usa sinais SIGUSR2 a cada poucos milissegundos para contabilização por query, criando muito mais eventos de delivery de sinal do que aplicações típicas e transformando uma corrida teoricamente possível em um crash de produção. A correção reordena instruções para que %rip seja lido antes de %rsp ser atualizado, eliminando a janela de corrida inteiramente. OpenAI upstreamed a correção e reprodutor para GNU libunwind.

Para praticantes debuggando crashes de produção com sintomas contraditórios: este case study demonstra que 'dados completos e rotulados em toda a população de falhas' é mais rápido do que análise mais profunda de casos individuais. A conclusão do team: 'O passo mais importante não era leitura inteligente de assembly ou conhecimento profundo dos detalhes. Era construir um dataset de alta qualidade.' Observação no nível de população revelou o que raciocínio caso-a-caso não pude: dois fenômenos não relacionados sendo conflacionados. Procure por este padrão em sua própria análise de incidente e considere se seu logging e captura de crash habilitam debugging no nível de população.