何か問題が発生した場合に備えて、当社の製品はミニダンプ ファイルを生成します。ダンプ ファイルから適切なスタック トレースを取得できるように、ビルドのデバッグ シンボルを格納およびアクセスするためにシンボル サーバーを実行します。
私たちの製品は他のオペレーティング システム (特に Linux と OS X) でも動作するため、Google ブレークパッドを検討し始めました。私もミニダンプとストレージ用の PDB ファイルを使用しているようです。しかし、私は疑問に思います：
(どのように) 既存のすべてのシンボルを失わないように、既存のシンボル サーバーを Google ブレークパッドに移行できますか? 他の人がすでに同じ動きをしていると思いますが、これには共通のアプローチがあるのではないでしょうか?
いくつかのオプションがあります:
サーバーに既にあるすべての pdb で dump_syms (これは、pdb をテキストベースのブレークパッドの .sym 形式に処理するツールであり、ブレークパッドに付属しています) を実行し、それらをブレークパッド サーバーにアップロードします (いくつかのオプションがあります。ここでは socorro を使用します)。また、関心のあるビルドのすべての新しいシンボルで実行し続ける必要があります。
入ってくるクラッシュを処理しているときに、stack_walker が必要とするため、サーバーからシンボルを要求します (まだ行っていません)。
最後の数回のクラッシュで不足しているシンボルを定期的に探し、それらがシンボル サーバー上にあるかどうかを確認し、それらを dump_syms で実行し、.syms をクラッシュ サーバーにアップロードしてから、クラッシュを再処理に送信します。
システム シンボルの MS シンボル サーバーをヒットする必要があるため、そのためだけに後のオプションの 1 つを実装する必要があります。
システム シンボルにはオプション 3 を使用しましたが、実装は使用するクラッシュ サーバーに大きく依存します (推奨される構成ではなく、socorro crash-stats を使用しています)。MS シンボル サーバー統合の複数の Python 実装があります。stack_walker からシンボルの名前と GUID がわかるため、PE 解析部分は無視できます。
注意すべき問題: OSX にはシンボル サーバーの概念がなく、ブレークパッド クラッシュ ダンプは役に立ちません。OSX クラッシュからスタック トレースを再構築するには、元のシステム バイナリにアクセスする必要があります (それらを dump_syms で実行するため)。これは常に可能であるとは限りません。OSX シンボルのリポジトリを手動で構築する必要があります。これも参照してください: https://wiki.mozilla.org/Breakpad:Symbols
キャッチ #2: Windows は大文字と小文字を区別しない FS を使用しており (驚き)、生成された pdb が正当な理由もなくリンカによって小文字化されることがあります (これを使用する PE バイナリはまだ適切な大文字と小文字を参照しています)。これは、クラッシュ サーバーが *nix マシンで実行されている場合に頭痛の種になります。この場合、pdb ファイル名に依存するのではなく、PE バイナリ自体からシンボル名を抽出することを検討してください。
キャッチ #3: ブレークパッドによってアップロードされたダンプ ファイルをデバッグするためにシンボル サーバーを実行する必要があります (スタック トレースが十分でなく、Visual Studio でダンプを開きたい場合)。BPはシンボル サーバーを使用し、それを置き換えません。