OpenAI core dump revela falha de hardware e bug de 18 anos

Introdução

OpenAI core dump não é apenas um termo técnico, é a peça que desencadeou uma investigação que encontrou duas causas reais para crashes em produção, uma falha de hardware silenciosa e um bug de 18 anos no GNU libunwind. O caso foi detalhado no post lançado em 30 de junho de 2026, que descreve como a equipe conectou indícios de múltiplos core dumps até chegar a um host defeituoso e a uma rara condição de corrida na rotina _Ux86_64_setcontext. O relato completo está em https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug/, referência que centraliza os dados e as correções aplicadas.

O valor do estudo vai muito além de um incidente. A narrativa entrega um manual prático de como times de plataforma podem combinar logs, dumps e telemetria para formar um dataset populacional de crashes e separar síndromes que se misturam em produção. Essa mudança de foco, de analisar o “paciente” isolado para entender a “população”, transformou um bug aparentemente impossível em dois problemas solucionáveis.

O que aconteceu, em termos simples

A OpenAI observou falhas esporádicas dentro do Rockset, motor de busca e análise em tempo real que foi adquirido em 21 de junho de 2024 e hoje é parte central da infraestrutura de dados que alimenta features de busca e plugins do ChatGPT. Em vários crashes, funções C++ terminavam e tentavam retornar para endereços inválidos, por vezes com o endereço de retorno igual a NULL, ou com o registrador %rsp desalinhado em 8 bytes. Nada disso é comum em código de aplicação sem assembly inline ou chamadas a setcontext e longjmp. Depois de muitas hipóteses descartadas, a equipe encontrou duas origens diferentes: um host físico com corrupção silenciosa causando registros incorretos, e uma condição de corrida muito estreita no GNU libunwind durante o desenrolar de exceções C++.

Esse diagnóstico foi possível quando o time construiu um pipeline para processar core dumps em lote, extrair registradores e rotular automaticamente cada caso. Com o dataset limpo em mãos, padrões claros emergiram. Os crashes de pilha desalinhada vinham de uma única região e de VMs que esbarravam sempre no mesmo host físico. Já os retornos para NULL se correlacionavam com caminhos de exceção, indicando um problema na biblioteca de unwinding.

H2. Rockset, C++ e o contexto operacional

O Rockset é um sistema de dados cloud nativo usado na OpenAI para indexação em tempo real e busca de conhecimento durante a inferência. Ele é escrito em C++ para extrair desempenho e eficiência de memória, o que é crucial em cargas de alto QPS. O lado B dessa escolha é conhecido, insegurança de memória e interação direta com registradores expõem a aplicação a falhas difíceis de reproduzir e classificar. Para reduzir impacto, os nós de processamento são replicados e há coleta sistemática de core dumps para análises a posteriori.

A aquisição do Rockset em 2024 integra tecnologia de indexação e consulta que habilita buscas rápidas sobre dados proprietários dos clientes, um pilar para recursos de RAG e agentes corporativos. Esse contexto explica por que confiabilidade e latência do pipeline de ingestão e consulta são prioridades estratégicas.

H2. Do “médico” ao “epidemiologista” dos crashes

Analisar manualmente alguns core dumps faz parte da rotina de qualquer engenheiro de backend. O salto de produtividade veio quando a equipe parou de olhar cada crash como um caso isolado e decidiu entender a população inteira, conectando cada dump a metadados como região, SKU de hardware, versão de kernel e timestamp. O pipeline baixou prefixos dos arquivos, extraiu registradores e classificou automaticamente causalidades prováveis, reduzindo falsos positivos e falsos negativos que ocorriam ao depender apenas de logs textuais. De repente, dois clusters bem distintos apareceram.

• Cluster A, desalinhamento de stack, concentrado em uma região específica, com data de início nítida, comportamento típico de host físico defeituoso afetando VMs que rodam ali.
• Cluster B, retorno para endereço inválido durante unwind de exceções, distribuído em várias regiões, sem fronteiras de infraestrutura claras, padrão consistente com problema em biblioteca de runtime.

Esse jeito de pensar em “epidemiologia de crashes” é replicável. Em ambientes multi-região e multi-SKU, mapear cada evento a atributos de infraestrutura e versão cria o terreno onde as correlações corretas se revelam em horas, não semanas.

H2. Falha de hardware, o host “ruim” e corrupção silenciosa

Quando o time isolou o cluster A, encontrou um host físico defeituoso. O time não conseguiu reproduzir a corrupção de registradores sob estresse controlado, mas assim que o host foi retirado de serviço, os crashes com %rsp desalinhado sumiram. A medida imediata foi negar lista para aquele host e fortalecer ferramentas operacionais, como incluir estado de registradores no fatal signal handler, facilitar a reutilização de VMs para acelerar a detecção de nós ruins e atualizar runbooks com o cenário de hardware defeituoso.

Falhas de hardware silenciosas, conhecidas como silent data corruption, são um problema amplamente documentado em escala de nuvem, indo além de memória e armazenamento e podendo afetar também CPUs, com erros aritméticos que passam sem alerta. O guia do Google Cloud usa inclusive o exemplo clássico, a CPU que “erra a conta”, e recomenda triagem rápida e remoção de hardware problemático. O caso da OpenAI ecoa essas melhores práticas.

![Ventoinhas de servidores em data center]

H2. O bug de 18 anos no GNU libunwind

Separado o ruído do hardware, ficou claro que o cluster B ocorria durante o desenrolar de exceções C++. O binário da OpenAI estava linkado a duas implementações de unwinding, a do libgcc e a do GNU libunwind, e por regras de linkagem dinâmica, a do GNU libunwind acabou ativa. O mecanismo de unwind sintetizava um ucontext_t na stack, preenchia o estado de registradores do frame de destino e chamava _Ux86_64_setcontext para restaurar esse estado. Aí mora a condição de corrida.

O assembly da rotina, na versão usada, ajustava %rsp para o novo fundo da pilha e, após esse ajuste, ainda lia campos do ucontext_t que havia sido colocado em uma região da stack que já não era mais “ativa” para o kernel. Se, nesse estreitíssimo intervalo de uma instrução, chegasse um sinal como o SIGUSR2 usado pela OpenAI para amostrar tempo de CPU por tarefa, o kernel poderia escrever a frame de sinal em %rsp-128 e sobrescrever partes do ucontext_t. Se a posição onde estava o novo %rip fosse atingida, o destino virava NULL, parecendo um retorno normal para endereço inválido. Raro, mas possível, e em escala, suficiente para mais de uma dezena de crashes diários.

A correção foi dupla. No curto prazo, a OpenAI migrou para o unwinder do libgcc, que também traz ganhos de contenção de locks. Em paralelo, upstream foi enviado um reprodutor e um patch para o GNU libunwind, ajustando _Ux86_64_setcontext para não ler mais do stack antigo após atualizar %rsp. O commit público documenta o rearranjo das leituras, com salvamento de valores antes da troca de stack, eliminando a janela de corrida.

H2. Por que o bug apareceu agora, depois de 18 anos

Três fatores multiplicaram o risco ao ponto de tornar o bug observável no ambiente da OpenAI. Primeiro, taxas altas de lançamento de exceções, parte do mecanismo de backpressure no ingest. Segundo, entrega frequente de sinais SIGUSR2 para amostragem do tempo de CPU de threads. Terceiro, uma mudança recente na handler de sinal que passou a usar mais stack, após a adição de timer_getoverrun. Antes dessa alteração, não havia crashes do tipo. Depois, com aumento de carga e mais exceções, a taxa se tornou operacionalmente visível. O raciocínio de “ordens de grandeza” fecha a conta, mesmo com uma janela de corrida de aproximadamente centenas de picosegundos.

O resultado lembra uma máxima de engenharia de confiabilidade. Bugs “impossíveis” emergem quando produto de taxas independentes cruza um limiar. Em ambientes com muita exceção, muito sinal e handlers fundos, condições de corrida de uma instrução passam de astronômicas para prováveis em escala de frota.

H2. Lições práticas para times de dados, SRE e C++

• Colete e trate core dumps como dados, não como artefatos pontuais. Construa um pipeline para extrair registradores e rótulos, consolide por região, SKU, versão de kernel e release. Aplainar ruídos é o que abre caminho para correlações.
• Separe populações antes de concluir causalidade. Misturar fenômenos mascara padrões, e hipóteses ficam se anulando. A virada no caso da OpenAI veio ao dividir os clusters com base em sinais fortes de infraestrutura.
• Tenha um plano para hardware defeituoso. Adote sinalização nos handlers fatais, reuse VMs para facilitar detecção de nós ruins, e garanta automação para negar lista e isolar hosts. Documentação de nuvem reforça que SDC existe e precisa de triagem disciplinada.
• Entenda profundamente o runtime de exceções. Se sua aplicação C++ depende de unwinding intenso e usa sinais com alta frequência, avalie qual unwinder está ativo, seu assembly e sua segurança assíncrona. Considere migrar para implementações mais robustas e, quando possível, contribuir com fixes upstream.
• Modele o risco como produto de taxas. Multiplique frequência de exceções por frequência de sinais e por profundidade de stack do handler. Se o resultado cruza um limiar, refatore. Pequenas mudanças, como reduzir stack do handler, trocar a fonte de tempo, ou amortecer exceções, derrubam o risco.

![Close-up de CPU em macro]

H2. Impacto estratégico para IA corporativa

A compra do Rockset em 2024 tinha um objetivo claro, acelerar buscas de baixa latência sobre dados proprietários em produtos como o ChatGPT Enterprise. Em 2026, isso já significa agentes que consultam bases vivas durante a inferência. Crashes nessa trilha não são só incidentes, são perdas diretas de confiabilidade de recursos críticos para adoção corporativa. Fortalecer o pipeline de diagnóstico, endurecer o runtime e remover hosts defeituosos protege a confiança do cliente.

Essa história também ilustra a importância de escolher bem as dependências em camadas críticas. Bibliotecas de sistema, especialmente as que manipulam contexto de execução, precisam de escrutínio contínuo. Ter capacidade interna de ler assembly, entender ABI e reproduzir condições de corrida torna as equipes mais independentes e rápidas para corrigir e contribuir com a comunidade.

Reflexões e insights

• Epidemiologia de falhas é um mindset que se paga. Em vez de caçar um crash por vez, invista em dados e rótulos que ajudem a contar a história da frota. Quando o dataset melhora, o debugging fica simples.
• Quando um bug “de sempre” aparece “de repente”, procure multiplicadores, aumentos de taxa e mudanças recentes no ambiente. No caso, sinais mais frequentes e handler mais profundo cruzaram o limiar.
• Silent data corruption não é lenda urbana. Em escala de nuvem, acontece, e o caminho é triagem agressiva, automação para isolar nós ruins e telemetria que exponha padrões.
• Investir em redundância e replicação amortiza impacto, mas não substitui correção de raiz. A duplicidade de causas aqui reforça que confiabilidade é tanto engenharia de software quanto gestão de infraestrutura.

Conclusão

O caso da OpenAI confirma uma premissa simples. Escala amplifica probabilidades minúsculas até que virem incidentes reais. Ao tratar core dumps como dados, o time separou um host defeituoso de um bug de 18 anos no GNU libunwind e aplicou correções que diminuem o risco estrutural, migrando para libgcc e contribuindo com patch upstream. Resultado, menos crashes, maior previsibilidade e runbooks mais inteligentes.

Para líderes técnicos e engenheiros, a mensagem é pragmática. Crie infraestrutura de observabilidade que facilite diagnósticos populacionais, aceite que SDC existe e precisa de resposta rápida, e trate runtime de exceções como componente de missão crítica. Em um stack que inclui C++ de alta performance, sinais frequentes e agentes de IA sob demanda, isso é a diferença entre incidentes enigmáticos e uma operação confiável.