Epidemiologia de core dump: corrigindo um bug de 18 anos na infraestrutura

A chamada 'epidemiologia de core dump' usada pela OpenAI não é uma nova ferramenta, mas uma metodologia escalável de análise de falhas raras: coletar, normalizar e comparar milhares de core dumps gerados em produção para identificar padrões estatísticos. O caso mais notável foi a descoberta de uma race condition na biblioteca GNU libunwind, código aberto mantido desde 2007, que só se manifestava sob carga extrema e combinações específicas de otimizações do GCC e configurações de stack alignment. A falha de hardware, por sua vez, foi detectada ao cruzar dados de core dump com métricas de hardware da Azure (como registros de MCE, Machine Check Exceptions), revelando corrupção silenciosa em CPUs Intel Xeon Platinum 8360Y+ em um único data center.

O bug de 18 anos não estava no código da OpenAI, mas em uma dependência crítica usada por quase todos os sistemas Linux que fazem stack unwinding em C++ (incluindo o próprio GDB). Ele afeta aplicações que usam exceções, setjmp/longjmp ou qualquer profiling com backtrace. Não há CVE atribuído até hoje, e o patch ainda não foi incorporado à versão estável do libunwind, apenas em um branch experimental mantido pela equipe da OpenAI no GitHub, com pull request pendente desde maio de 2026.

Esse caso mostra que bugs antigos em bibliotecas de baixo nível continuam vivos em produção, mesmo em infraestruturas de ponta. A maioria dos times de SRE e DevOps ignora core dumps como artefatos de depuração 'legados', priorizando logs e métricas. Mas falhas de memória e corrupção silenciosa frequentemente deixam poucos rastros fora do core dump. A OpenAI demonstrou que, com automação de extração (usando scripts em Python + GDB Python API) e clustering de stacks (com t-SNE e análise de similaridade de frames), é possível transformar centenas de dumps esparsos em evidência diagnóstica robusta, algo que métodos tradicionais de observabilidade não capturam.

Desenvolvedores em C/C++ e Rust devem revisar seus pipelines de CI para incluir testes de stack unwinding sob pressão, especialmente com ASan + UBSan ativados e variações de otimização (-O2 vs -O3). Times que usam libunwind (direta ou indiretamente via gperftools, abseil ou LLVM libc++) devem validar se estão usando versões com o patch da OpenAI ou alternativas como libbacktrace. Para quem ativa core dumps em produção: configure /proc/sys/kernel/core_pattern para redirecionar para um sistema de armazenamento confiável (não /tmp) e valide se seu GDB suporta debuginfo remoto via DWARF v5, muitos dumps recentes exigem isso para decodificar frames corretamente. O CLI do Codex com bug de escrita excessiva em SQLite também serve como alerta: ferramentas locais de IA devem ter limites explícitos de I/O e verificação de tamanho de arquivo antes de persistir dados.