Bunの新しいクラッシュレポーター

Bunの新しい Crash Reporter

• Bun v1.1.5では、ZigとC++向けの新しいクラッシュレポート形式を作成
• クラッシュレポートは、個人情報をまったく含まない約150バイトのURLに収まる

なぜOSのクラッシュレポーターを使わないのか？

• macOSのように一部のOSには組み込みのクラッシュレポーターがあるが、通常はデバッグシンボルをアプリケーションと一緒に配布する必要がある
• Linux向けのデバッグシンボルは約30MB、macOSは約9MB
• Windowsの.pdbファイルは250MB以上
• Bunのすべてのインストールファイルに追加するには大きすぎる
• しかしデバッグシンボルがないと、クラッシュ情報は非常に限定的になり、ASLRのためにすべての関数アドレスが役に立たなくなる

新しいクラッシュレポーター

• Bun v1.1.5では、クラッシュやパニックが発生するとメッセージを出力する
• bun.reportリンクをクリックすると、スタックトレースがURLにエンコードされた事前入力済みのGitHub Issueテンプレートへリダイレクトされる

アドレスを有用なものにする

• 関数アドレスは、セキュリティ上の理由でランダム化されたオフセットを含む、アプリケーションコードが読み込まれているメモリへのポインタ
• コツは、単純にバイナリのベースアドレスからそのアドレスを引くこと
• プラットフォームごとに異なるAPIがあるため、実際にはこの関数ははるかに複雑
• 結果のアドレスには、依然としてイメージへのオフセットが含まれている
• より短いURLをエンコードするため、このオフセットは削除されるが、再マッピング前に再び追加する必要がある

bun.reportのURL構造

• URLがどのようにエンコードされているかを分析すると:
  • プラットフォーム : プラットフォームを表す1文字。wはx86_64 Windows、Mはaarch64 macOSなど
  • サブコマンド : bun test、bun install、bun runなどのサブコマンドを表す1文字
  • コミットSHA : 現在のBunバージョンのコミットSHA。後でデバッグシンボルを取得するのに使われる
  • Feature Flags : Bunがクラッシュする前に使用されていたAPIや機能を示すフラグ
  • スタックトレースアドレス : 前述の計算済みアドレス
  • クラッシュタイプ : クラッシュの種類を表す1文字
  • クラッシュメッセージ : クラッシュのメッセージで、タイプによって形式が異なる

VLQは楽しい

• URLを適度に短く保つため、スタックトレースアドレスはbase64の可変長数量を使ってエンコードされる
• 小さな数値はより少ない文字でエンコードできる一方で、大きな数値も引き続きエンコードできる
• JavaScriptのソースマップで行番号を保存するのに使われているのと同じ技術

"Feature"とは何か？

• URLはまた、各ビットがBunの特定機能の使用有無に対応する64ビット整数もエンコードしている
• これらのフラグは、クラッシュにつながる可能性のあるAPIやシステムについてのヒントを与える
• Zigのコンパイル時メタプログラミングにより、このビットフィールドを簡単に作成できる
• 機能追跡のためのグローバル変数コンテナはすでに存在していた
• std.metaを使って機能一覧を反復処理し、リストを作れる
• その後、機能ごとに1ビットを使うよう動的に導出されたpacked構造体を作成できる

これはコアダンプとどう比較されるか？

• コアダンプにははるかに多くの情報が含まれるが、サイズが大きく、デバッグシンボルがなければ有用ではなく、さらに機密性の高い情報や秘密情報を多く含む可能性がある
• JavaScript/TypeScriptのソースコード、環境変数、その他の重要情報がレポートに送られる可能性は避けたかった
• そのため、Zig/C++のスタックトレースといくつかの詳細だけを送るようにしている
• すべてをデフォルトで送るのではなく、このアプローチでは（おそらく）問題の診断に必要なものだけを送る

デモ

• クラッシュレポーターをテストできる小さなWebアプリが、bun.reportのホームページで利用できる
• クラッシュレポートURLの末尾に/viewを追加すると、そこに到達する

Bunはサンフランシスコで採用中

• このようなプロジェクトに興味があれば、サンフランシスコでエンジニアを募集している
• JavaScriptの未来を作るのを手伝ってくれるシステムエンジニアを探している

GN+の意見

• 個人情報などの機微な情報を含む可能性があるクラッシュダンプファイル全体を送るのではなく、最小限必要な情報だけで構成されたクラッシュレポートを送る方式は、良いアプローチに見えます。

• コアダンプと比べてはるかに少ない容量で必要な情報を提供できるのは利点ですが、デバッグに必要な情報が不足する可能性があるという欠点もありそうです。必要に応じてユーザーに追加情報を求められるという点で、この欠点はある程度カバーできるでしょう。

• VLQを使ってスタックトレースアドレスをエンコードするアイデアは印象的です。小さなサイズで多くの情報を伝えられる効率的な方法ですね。JavaScriptのソースマップで使われる技術だというのも面白い活用例です。

• 全体として、クラッシュレポートシステムの設計には多くの検討と創造的なアイデアが込められているように思います。実際のクラッシュレポートを通じて、Bunの安定性と使いやすさの改善に大きく貢献しそうです。

• 基本レポートでは提供されない追加情報が必要な場合、ユーザーがクラッシュレポートの各フィールドについて自分で把握して提供しなければならないかもしれず、上級ユーザーでなければ理解が難しい可能性もあります。これをよりユーザーフレンドリーに改善する方法も検討に値します。