Buns neuer Crash Reporter

Buns neuer Crash Reporter

• Bun v1.1.5 führt ein neues Crash-Report-Format für Zig und C++ ein
• Der Crash-Report passt in eine etwa 150 Byte große URL und enthält keinerlei persönliche Informationen

Warum nicht den Crash Reporter des Betriebssystems verwenden?

• Einige Betriebssysteme wie macOS haben einen eingebauten Crash Reporter, aber dafür müssen in der Regel Debug-Symbole zusammen mit der Anwendung ausgeliefert werden
• Debug-Symbole für Linux sind etwa 30 MB groß, für macOS etwa 9 MB
• Unter Windows sind .pdb-Dateien mehr als 250 MB groß
• Das ist zu viel, um es allen Bun-Installationsdateien hinzuzufügen
• Ohne Debug-Symbole sind die Crash-Informationen jedoch sehr begrenzt, und durch ASLR werden alle Funktionsadressen unbrauchbar

Der neue Crash Reporter

• In Bun v1.1.5 wird bei einem Crash oder Panic eine Meldung ausgegeben
• Wenn man auf den bun.report-Link klickt, wird man zu einer vorausgefüllten GitHub-Issue-Vorlage weitergeleitet, in der der Stack Trace in die URL kodiert ist

Adressen nutzbar machen

• Funktionsadressen sind Zeiger auf den Speicher, in den der Anwendungscode geladen wird, einschließlich eines aus Sicherheitsgründen randomisierten Offsets
• Der Trick besteht einfach darin, die Basisadresse der Binärdatei von der Adresse abzuziehen
• Da jede Plattform andere APIs hat, ist diese Funktion in der Praxis deutlich komplexer
• Die resultierende Adresse enthält weiterhin einen Offset relativ zum Image
• Für kürzere URLs wird dieser Offset entfernt, muss aber vor dem Remapping wieder hinzugefügt werden

Die URL-Struktur von bun.report

• Wenn man analysiert, wie die URL kodiert ist:
  • Plattform: Ein einzelnes Zeichen, das die Plattform angibt. w steht für x86_64 Windows, M für aarch64 macOS usw.
  • Subcommand: Ein einzelnes Zeichen für Subcommands wie bun test, bun install, bun run usw.
  • Commit-SHA: Die Commit-SHA der aktuellen Bun-Version. Sie wird später verwendet, um Debug-Symbole abzurufen
  • Feature Flags: Kennzeichnungen für APIs und Funktionen, die vor dem Crash von Bun verwendet wurden
  • Stack-Trace-Adressen: Die zuvor berechneten Adressen
  • Crash-Typ: Ein einzelnes Zeichen, das die Art des Crashs angibt
  • Crash-Meldung: Die Meldung des Crashs, deren Format je nach Typ unterschiedlich ist

VLQ macht Spaß

• Damit die URL ausreichend kurz bleibt, werden die Stack-Trace-Adressen mit base64-codierten variablen Längenmengen kodiert
• Kleine Zahlen lassen sich mit weniger Zeichen kodieren, während trotzdem große Zahlen dargestellt werden können
• Das ist dieselbe Technik, die in JavaScript-Source-Maps zum Speichern von Zeilennummern verwendet wird

Was ist ein "Feature"?

• Die URL kodiert außerdem eine 64-Bit-Ganzzahl, bei der jedes Bit dafür steht, ob eine bestimmte Bun-Funktion verwendet wurde
• Diese Flags liefern Hinweise auf APIs und Systeme, die zu dem Crash geführt haben könnten
• Zig-Compile-Time-Metaprogrammierung macht es einfach, dieses Bitfeld zu erzeugen
• Es gab bereits einen Container für globale Variablen zur Verfolgung von Features
• Mit std.meta lässt sich über die Feature-Liste iterieren und eine Liste erstellen
• Anschließend kann man dynamisch eine gepackte Struktur ableiten, die pro Feature ein Bit verwendet

Wie verhält sich das im Vergleich zu einem Core Dump?

• Core Dumps enthalten viel mehr Informationen, sind aber groß, nur mit Debug-Symbolen wirklich nützlich und enthalten potenziell viele sensible oder vertrauliche Daten
• Man wollte vermeiden, dass JavaScript-/TypeScript-Quellcode, Umgebungsvariablen oder andere wichtige Informationen im Report landen
• Deshalb werden nur der Zig/C++-Stack-Trace und einige wenige weitere Details übertragen
• Statt standardmäßig alles zu senden, überträgt dieser Ansatz (vermutlich) nur das, was zur Diagnose des Problems nötig ist

Demo

• Auf der Startseite von bun.report gibt es eine kleine Web-App, mit der sich der Crash Reporter testen lässt
• Wenn man /view an das Ende einer Crash-Report-URL anhängt, landet man dort

Bun stellt in San Francisco ein

• Wer sich für Projekte wie dieses interessiert: In San Francisco werden Ingenieure eingestellt
• Gesucht werden Systemingenieure, die dabei helfen wollen, die Zukunft von JavaScript zu gestalten

Meinung von GN+

• Statt die komplette Crash-Dump-Datei zu senden, die sensible Informationen wie persönliche Daten enthalten könnte, scheint der Ansatz gut zu sein, nur einen Crash-Report mit den minimal nötigen Informationen zu verschicken.

• Gegenüber einem Core Dump ist es ein Vorteil, die benötigten Informationen mit deutlich geringerem Umfang bereitstellen zu können. Allerdings könnte auch der Nachteil bestehen, dass für das Debugging wichtige Informationen fehlen. Dieser Nachteil lässt sich bis zu einem gewissen Grad dadurch abfedern, dass man Nutzer je nach Bedarf um zusätzliche Informationen bitten kann.

• Die Idee, Stack-Trace-Adressen mit VLQ zu kodieren, ist beeindruckend. Es ist eine effiziente Methode, mit kleiner Größe viele Informationen zu übertragen. Dass dafür eine Technik aus JavaScript-Source-Maps verwendet wird, ist ein interessantes Anwendungsbeispiel.

• Insgesamt scheint in das Design dieses Crash-Reporting-Systems viel Überlegung und Kreativität eingeflossen zu sein. Über echte Crash-Reports könnte es erheblich zur Verbesserung von Stabilität und Benutzbarkeit von Bun beitragen.

• Falls zusätzliche Informationen benötigt werden, die im Standard-Report nicht enthalten sind, müssten Nutzer die einzelnen Felder des Crash-Reports wohl selbst verstehen und bereitstellen. Für Anwender ohne tieferes technisches Wissen könnte das schwer nachvollziehbar sein. Es wäre sinnvoll, auch über benutzerfreundlichere Verbesserungen nachzudenken.