Le nouveau crash reporter de Bun

Le nouveau Crash Reporter de Bun

• Bun v1.1.5 introduit un nouveau format de rapport de crash pour Zig et C++
• Le rapport de crash tient dans une URL d’environ 150 octets, sans aucune donnée personnelle

Pourquoi ne pas utiliser le crash reporter de l’OS ?

• Certains OS comme macOS ont un crash reporter intégré, mais il faut généralement fournir les symboles de débogage avec l’application
• Les symboles de débogage pour Linux pèsent environ 30 Mo, ceux de macOS environ 9 Mo
• Sous Windows, les fichiers .pdb dépassent 250 Mo
• C’est trop volumineux pour être ajouté à tous les fichiers d’installation de Bun
• Mais sans symboles de débogage, les informations de crash sont très limitées, et l’ASLR rend toutes les adresses de fonctions inutiles

Le nouveau crash reporter

• Dans Bun v1.1.5, un message s’affiche lorsqu’un crash ou une panique se produit
• Cliquer sur le lien bun.report redirige vers un formulaire de ticket GitHub prérempli, avec la stack trace encodée dans l’URL

Rendre les adresses utiles

• Les adresses de fonctions sont des pointeurs vers la mémoire où le code de l’application est chargé, avec un décalage aléatoire ajouté pour des raisons de sécurité
• L’astuce consiste simplement à soustraire l’adresse de base du binaire à l’adresse
• Chaque plateforme a une API différente, donc en pratique cette fonction est bien plus complexe
• L’adresse résultante inclut toujours un offset par rapport à l’image
• Pour encoder une URL plus courte, cet offset est supprimé, mais il doit être réajouté avant le remapping

Structure de l’URL de bun.report

• En analysant la manière dont l’URL est encodée :
  • Plateforme : un caractère unique qui représente la plateforme. w signifie Windows x86_64, M signifie macOS aarch64, etc.
  • Sous-commande : un caractère unique qui représente une sous-commande comme bun test, bun install, bun run, etc.
  • Commit SHA : le commit SHA de la version actuelle de Bun. Il sera utilisé plus tard pour récupérer les symboles de débogage
  • Feature Flags : indique quelles API et fonctionnalités ont été utilisées avant le crash de Bun
  • Adresses de la stack trace : les adresses calculées précédemment
  • Type de crash : un caractère unique qui représente le type de crash
  • Message de crash : le message du crash, dont le format varie selon le type

Le VLQ, c’est amusant

• Pour garder une URL raisonnablement courte, les adresses de la stack trace sont encodées en base64 à l’aide de quantités de longueur variable
• Cela permet d’encoder les petits nombres avec moins de caractères tout en conservant la possibilité d’encoder de grands nombres
• C’est la même technique que celle utilisée pour stocker les numéros de ligne dans les source maps JavaScript

Qu’est-ce qu’une « feature » ?

• L’URL encode aussi un entier 64 bits dont chaque bit correspond à l’utilisation ou non d’une fonctionnalité précise de Bun
• Ces flags donnent des indices sur les API et systèmes qui ont pu conduire au crash
• La métaprogrammation à la compilation de Zig permet de créer facilement ce champ de bits
• Il existait déjà un conteneur de variables globales pour le suivi des fonctionnalités
• std.meta permet d’itérer sur la liste des fonctionnalités et de générer une liste
• Il est ensuite possible de créer une struct packée dérivée dynamiquement, avec un bit par fonctionnalité

Comment cela se compare-t-il à un core dump ?

• Un core dump contient bien plus d’informations, mais il est volumineux, n’est utile qu’avec les symboles de débogage, et peut contenir beaucoup d’informations sensibles ou confidentielles
• Ils voulaient éviter la possibilité d’envoyer dans le rapport du code source JavaScript/TypeScript, des variables d’environnement ou d’autres informations importantes
• C’est pourquoi seuls la stack trace Zig/C++ et quelques autres détails sont envoyés
• Au lieu de tout envoyer par défaut, cette approche n’envoie (probablement) que ce qui est nécessaire pour diagnostiquer le problème

Démo

• Une petite web app permettant de tester le crash reporter est disponible sur la page d’accueil de bun.report
• Ajouter /view à la fin de l’URL du rapport de crash mène ici

Bun recrute à San Francisco

• Si ce type de projet vous intéresse, Bun recrute des ingénieurs à San Francisco
• Ils recherchent des ingénieurs systèmes pour aider à construire l’avenir de JavaScript

L’avis de GN+

• Au lieu d’envoyer un fichier complet de crash dump pouvant contenir des informations sensibles comme des données personnelles, envoyer un rapport de crash composé uniquement du minimum d’informations nécessaires semble être une bonne approche.

• Par rapport à un core dump, l’avantage est de pouvoir fournir les informations nécessaires avec un volume bien moindre, mais l’inconvénient est qu’il peut manquer des informations utiles au débogage. Ce point faible peut sans doute être compensé en demandant des informations supplémentaires à l’utilisateur selon les besoins.

• L’idée d’encoder les adresses de la stack trace avec du VLQ est impressionnante. C’est une méthode efficace pour transmettre beaucoup d’informations dans une taille réduite. Le fait que ce soit la même technique que celle utilisée dans les source maps JavaScript en fait un cas d’usage intéressant.

• Dans l’ensemble, on sent qu’il y a eu beaucoup de réflexion et d’idées créatives dans la conception de ce système de crash reporting. Avec les vrais rapports de crash, cela pourrait fortement contribuer à améliorer la stabilité et l’ergonomie de Bun.

• Si des informations supplémentaires, absentes du rapport par défaut, sont nécessaires, l’utilisateur devra probablement comprendre lui-même les champs du rapport de crash et fournir ces détails. Cela pourrait être difficile pour quelqu’un qui n’est pas un utilisateur avancé. Il vaudrait donc la peine de réfléchir à des améliorations plus conviviales.