1

問題の追跡にFogbugzを使用しており、FogbugzのXMLAPIの周りにC++ラッパーを作成している最中です。

ベストプラクティスは、「スカウト」フィールドを使用して、類似/同じクラッシュがカウントされるだけで、再度報告されないようにすることです。そのためには、クラッシュの特定の原因に対する一意の文字列が必要です。

Win32の場合-dmpファイルまたは他のクラッシュハンドラーを取得した後、クラッシュの一意の文字列を作成するための良い方法は何ですか？（dmpファイルを作成してfogbugzサーバーに送信します）

以前の投稿/記事などで、Joelはさまざまな提案をしましたが、それらの多くは、リフレクションを使用し、取得が難しいか取得できない多くの情報を持っているC＃のような言語に頼っています。

他の人は、スタックトレースや、fogbugzにスカウトエントリを作成するための他のものなどを入手しましたか？

編集明確にするために-すべてのインシデントに一意のIDは必要ありません-同じコードパスを持つクラッシュが発生する可能性があります。それを捉えたい。コードに含まれる最後の数個のスタック呼び出し（win32 DLLからの呼び出しではない）を取得することを考えていましたが、これを実行する方法がわかりません。

すべてのクラッシュを一意として報告するのは正しくありません。同じケースですべてのクラッシュを報告するのは正しくありません。クラッシュの原因となるシナリオを繰り返すさまざまなユーザーは、同じインシデントにマッピングする必要があります。

編集

私たちが望んでいるのは、スタックにあるものに基づいた、クラッシュの一般的な「シグネチャ」です。同様のスタックは同じ署名を持つ必要があります。たとえば、アプリにある上位5つのメソッドを取得してから、最初の呼び出し（存在する場合）をMSDLLにします。これはおそらく署名には十分であり、「同じ」クラッシュを相関させる可能性があります。

では、スタック上のメソッドのリストをどのように取得するのでしょうか。そして、それらが自分のアプリからのものか、別のDLLからのものかをどのように判断できますか？

編集-注ミニダンプを作成し、スカウトの説明としてfogbugzに送信できるように、例外ハンドラーで「バケットID」/署名を作成します。または、アプリの次の起動時にダンプをロードし、生成した署名を付けて送信することもできます。

4

6 に答える 6

1

ここで私のプロジェクトでは、クラッシュのアドレス メモリを「一意の」ID として使用します。

于 2011-01-06T19:16:09.007 に答える
1

IMO 使用できる最良のものは、ダンプ分析からのバケット ID です。適切に構成された Windows 用デバッグ ツール (windbg) を使用すると、!analyze -v を実行して、バケット ID に基づいてダンプを異なるバケットに分類できます。バケット ID は、2 つのダンプが同じ場合、それらのバケット ID が同じであることを保証します。これでパズルの一部が解決します。

多くの場合、同じ問題に由来する 2 つのダンプが異なるバケット ID を作成します (おそらくバージョンの違いで、1.0 と 1.1 の両方が同じ時点でクラッシュするとします)。フォルト モジュールとスタック シグネチャを使用して、同じフォルト ポイントからのバグを関連付けることができます。

非常にランダムなダンプの原因となる特定の事柄があります (たとえば、ヒープの破損、障害のあるモジュールが通常犠牲になります)。したがって、ダンプ分析はベスト エフォートと見なす必要があります。できないときはできない。

于 2011-01-07T07:12:26.780 に答える
1

このようなものを使用して、最後のアプリ (MSVC) で例外を生成したため、すべてのエラーがソースファイルと発生した行と共に記録されます。

class Error {
    //...
    public: Error(string file, string line, string error) ;
};

#define ERROR(err) Error(__FILE__, __LINE__, err)
于 2011-01-07T07:25:15.477 に答える
-1

まず、クラッシュレポートのスタックトレースで、コード内のすべての関数が「フラッシュ」された頻度に関するデータを収集することから始めます。すべてのレポートをある種のデータベースに追加する必要があり、後でクエリを実行できるようにすべての関数にインデックスを付ける必要があります。これらの関数は他の関数よりも頻繁にクラッシュするようです。（もちろん、main（）のような関数はすべてのレポートに含まれますが、それは理解できます）。

または、クラッシュレポートのみが問題であると思われる場合は、クラッシュスタックトレースからこれらのエントリをすべて削除し、残り（関数）をハッシュすることができます。そうすれば、間にどの外部関数が呼び出されたかに関係なく、独自の関数の特定の呼び出しチェーンが繰り返しクラッシュを引き起こすかどうかを確認できます。

もちろん、スタックトレースが完全に異なるため、より複雑な問題のいくつかは、とにかくこの方法ではキャプチャされません。これを支援するために、バッファのサイズ、カウンタ、アプリケーションのさまざまな部分の状態など、すべてのレポートのスタックトレースとともに、アプリケーションからの他のデータを記録できます。次に、その統計を実行します。

于 2011-01-06T21:19:55.080 に答える
-1

ダンプ ファイルから生成された MD5 文字列を使用するだけで、クラッシュごとに一意の文字列が得られる可能性があります。

于 2011-01-06T19:14:26.080 に答える