O novo crash reporter do Bun

O novo Crash Reporter do Bun

• O Bun v1.1.5 criou um novo formato de relatório de crash para Zig e C++
• O relatório de crash cabe em uma URL de cerca de 150 bytes, sem nenhuma informação pessoal

Por que não usar o crash reporter do sistema operacional?

• Alguns sistemas operacionais, como o macOS, têm crash reporters embutidos, mas normalmente exigem que símbolos de depuração sejam distribuídos junto com a aplicação
• Os símbolos de depuração para Linux têm cerca de 30MB, no macOS cerca de 9MB
• No Windows, arquivos .pdb têm mais de 250MB
• É grande demais para adicionar a todos os arquivos de instalação do Bun
• Mas, sem símbolos de depuração, as informações de crash ficam muito limitadas, e o ASLR faz com que todos os endereços de função se tornem inúteis

O novo crash reporter

• No Bun v1.1.5, quando ocorre um crash ou pânico, uma mensagem é exibida
• Ao clicar no link bun.report, ocorre um redirecionamento para um formulário pré-preenchido de issue no GitHub, com o stack trace codificado na URL

Tornando os endereços úteis

• Endereços de função são ponteiros para a memória onde o código da aplicação é carregado, incluindo um offset aleatorizado por razões de segurança
• O truque é simplesmente subtrair o endereço base do binário do endereço
• Cada plataforma tem APIs diferentes, então na prática essa função é bem mais complexa
• O endereço resultante ainda inclui um offset em relação à imagem
• Para codificar uma URL mais curta, esse offset é removido, mas precisa ser adicionado novamente antes do remapeamento

Estrutura da URL do bun.report

• Analisando como a URL foi codificada:
  • Plataforma : um único caractere que indica a plataforma. w é Windows x86_64, M é macOS aarch64 etc.
  • Subcomando : um único caractere que representa subcomandos como bun test, bun install, bun run etc.
  • Commit SHA : o commit SHA da versão atual do Bun. É usado depois para buscar os símbolos de depuração
  • Feature Flags : indicações sobre APIs e recursos usados pelo Bun antes de travar
  • Endereços do stack trace : os endereços calculados anteriormente
  • Tipo de crash : um único caractere que representa o tipo de crash
  • Mensagem de crash : a mensagem do crash, com formato diferente dependendo do tipo

VLQ é divertido

• Para manter a URL razoavelmente curta, os endereços do stack trace são codificados usando números de quantidade de comprimento variável em base64
• Isso permite que números pequenos sejam codificados com menos caracteres, sem deixar de representar números grandes
• É a mesma técnica usada para armazenar números de linha em source maps de JavaScript

O que é uma "feature"?

• A URL também codifica um inteiro de 64 bits em que cada bit corresponde ao uso de um recurso específico do Bun
• Essas flags dão pistas sobre APIs e sistemas que podem ter levado ao crash
• A metaprogramação em tempo de compilação do Zig facilita a criação desse campo de bits
• Já existia um contêiner de variáveis globais para rastrear recursos
• Com std.meta, é possível iterar pela lista de recursos e montar uma lista
• Depois, é possível criar uma struct compactada derivada dinamicamente para usar um bit por recurso

Como isso se compara a um core dump?

• Core dumps contêm muito mais informação, mas são grandes, só são úteis com símbolos de depuração e podem incluir muitos dados sensíveis ou confidenciais
• Queriam evitar a possibilidade de enviar no relatório código-fonte JavaScript/TypeScript, variáveis de ambiente ou outras informações importantes
• Por isso, enviam apenas o stack trace de Zig/C++ e alguns outros detalhes
• Em vez de enviar tudo por padrão, essa abordagem envia (provavelmente) apenas o necessário para diagnosticar o problema

Demo

• Há um pequeno webapp na página inicial do bun.report para testar o crash reporter
• Se você adicionar /view ao final da URL do relatório de crash, chegará a essa página

O Bun está contratando em São Francisco

• Se você tem interesse em projetos como este, a empresa está contratando engenheiros em São Francisco
• Estão procurando engenheiros de sistemas para ajudar a construir o futuro do JavaScript

Opinião do GN+

• Em vez de enviar o arquivo completo de crash dump, que pode conter informações sensíveis como dados pessoais, parece uma boa abordagem enviar um relatório de crash composto apenas pelas informações mínimas necessárias.

• Em comparação com um core dump, a vantagem é fornecer as informações necessárias com um tamanho muito menor, mas também parece haver a desvantagem de poder faltar informação necessária para depuração. Como é possível pedir informações adicionais ao usuário quando necessário, essa limitação pode ser compensada até certo ponto.

• A ideia de codificar endereços de stack trace com VLQ é impressionante. É uma forma eficiente de transmitir bastante informação em pouco espaço. O fato de ser uma técnica usada em source maps de JavaScript torna esse caso de uso ainda mais interessante.

• No geral, parece que houve muito cuidado e criatividade no design do sistema de relatórios de crash. Na prática, isso pode contribuir bastante para melhorar a estabilidade e a usabilidade do Bun por meio dos relatórios reais de crash.

• Caso sejam necessárias informações adicionais que não estão disponíveis no relatório padrão, o usuário talvez precise entender e fornecer manualmente os dados de cada campo do relatório de crash, o que pode ser difícil para quem não é um usuário avançado. Também vale considerar formas de tornar isso mais amigável para o usuário.