El nuevo reportero de fallos de Bun

El nuevo Crash Reporter de Bun

• En Bun v1.1.5 se creó un nuevo formato de reporte de fallos para Zig y C++
• El reporte de fallos cabe en una URL de unos 150 bytes sin ningún dato personal

¿Por qué no usar el crash reporter del sistema operativo?

• Algunos sistemas operativos como macOS tienen un crash reporter integrado, pero normalmente hay que distribuir los símbolos de depuración junto con la aplicación
• Los símbolos de depuración para Linux pesan alrededor de 30 MB, en macOS unos 9 MB
• En Windows, los archivos .pdb superan los 250 MB
• Es demasiado peso como para añadirlo a todos los instaladores de Bun
• Pero sin símbolos de depuración, la información del fallo es muy limitada, y ASLR hace que todas las direcciones de funciones dejen de ser útiles

El nuevo crash reporter

• En Bun v1.1.5, cuando ocurre un fallo o pánico, se muestra un mensaje
• Al hacer clic en el enlace bun.report, se redirige a un formulario de issue de GitHub ya preparado, con el stack trace codificado en la URL

Hacer útiles las direcciones

• Las direcciones de funciones son punteros a la memoria donde se carga el código de la aplicación, con un offset aleatorizado por razones de seguridad
• El truco consiste simplemente en restar la dirección base del binario a la dirección
• Cada plataforma tiene APIs distintas, así que en la práctica esta función es bastante más compleja
• La dirección resultante todavía incluye un offset con respecto a la imagen
• Para codificar una URL más corta, ese offset se elimina, pero debe volver a añadirse antes de remapear

La estructura de la URL de bun.report

• Si analizamos cómo se codificó la URL:
  • Plataforma: un solo carácter que indica la plataforma. w es Windows x86_64, M es macOS aarch64, etc.
  • Subcomando: un solo carácter que representa subcomandos como bun test, bun install, bun run, etc.
  • Commit SHA: el commit SHA de la versión actual de Bun. Más adelante se usa para obtener los símbolos de depuración
  • Feature Flags: indicadores sobre las APIs y funciones usadas antes de que Bun fallara
  • Direcciones del stack trace: las direcciones calculadas anteriormente
  • Tipo de fallo: un solo carácter que representa el tipo de fallo
  • Mensaje del fallo: el mensaje del fallo, con formato distinto según el tipo

VLQ es divertido

• Para mantener la URL razonablemente corta, las direcciones del stack trace se codifican usando números de cantidad variable en base64
• Esto permite codificar números pequeños con menos caracteres, sin dejar de poder representar números grandes
• Es la misma técnica que se usa para guardar números de línea en los source maps de JavaScript

¿Qué es una "feature"?

• La URL también codifica un entero de 64 bits donde cada bit corresponde a si se usó o no una función específica de Bun
• Estas flags dan pistas sobre las APIs y sistemas que pudieron llevar al fallo
• La metaprogramación en tiempo de compilación de Zig permite crear este bitfield fácilmente
• Ya existía un contenedor de variables globales para rastrear funciones
• Con std.meta se puede iterar sobre la lista de funciones y construir una lista
• Luego se puede crear una struct empaquetada derivada dinámicamente para usar un bit por cada función

¿Cómo se compara esto con un core dump?

• Un core dump contiene mucha más información, pero es grande, solo es útil si hay símbolos de depuración y potencialmente incluye muchos datos sensibles o confidenciales
• Querían evitar la posibilidad de enviar código fuente de JavaScript/TypeScript, variables de entorno u otra información importante en el reporte
• Por eso solo envían el stack trace de Zig/C++ y algunos otros detalles
• En lugar de enviar todo por defecto, este enfoque manda (probablemente) solo lo necesario para diagnosticar el problema

Demo

• En la página principal de bun.report hay una pequeña web app para probar el crash reporter
• Si agregas /view al final de la URL del reporte de fallo, llegas ahí

Bun está contratando en San Francisco

• Si te interesan proyectos como este, están contratando ingenieros en San Francisco
• Están buscando ingenieros de sistemas que ayuden a construir el futuro de JavaScript

Opinión de GN+

• En lugar de enviar el archivo completo del volcado de fallos, que puede incluir información sensible como datos personales, parece un buen enfoque enviar un reporte de fallos compuesto solo por la información mínima necesaria.

• Frente a un core dump, poder proporcionar la información necesaria con mucho menos tamaño es una ventaja, aunque también parece tener la desventaja de que podría faltar información necesaria para depurar. Como se puede pedir información adicional al usuario según haga falta, ese punto débil probablemente se puede cubrir hasta cierto grado.

• La idea de codificar las direcciones del stack trace con VLQ me parece llamativa. Es una forma eficiente de transmitir mucha información en poco espacio. Que sea una técnica usada en los source maps de JavaScript lo hace un caso de uso interesante.

• En general, parece que hay mucha reflexión e ideas creativas detrás del diseño de este sistema de reporte de fallos. Da la impresión de que podría contribuir bastante a mejorar la estabilidad y usabilidad de Bun mediante reportes reales.

• Si se necesita información adicional que no viene en el reporte base, parece que el usuario tendría que identificar y proporcionar por su cuenta la información de cada campo del reporte de fallos, lo cual podría ser difícil de entender para alguien que no sea un usuario avanzado. También valdría la pena pensar en formas de hacerlo más amigable para el usuario.