問題タブ [postmortem-debugging]

ミニダンプ ファイルの MiscInfoStream には、プロセスの作成時間が含まれています。クラッシュする前にプロセスが実行されていた時間を知りたいです。ミニダンプ ファイルには、例外のタイムスタンプがどこかに含まれていますか?

このダンプ ファイルの WinDbg は、次のように表示されます。これは、それがどこかにあることを意味します...

(DumpChk は、ストリームのリストの最後に同じ情報を表示します)

今日は 3 月 15 日なので、これがほぼ確実にクラッシュのタイムスタンプであることに注意してください。その値と「プロセス稼働時間」の値をプログラムで取得する方法が必要です。

MINIDUMP_MISC_INFO_3タイムゾーン情報を含む構造体を見つけましたが、例外時間が含まれていないようです。

一部のダンプ ファイルには、プロセス内の各スレッドのタイムスタンプを含む ThreadInfoListStream が含まれているように見えますが、これは私が確認したミニダンプには含まれていません。

私は自分の質問で問題を解決したくないことに注意してください-私は物事が起こる可能性について考えていたので、何かについて疑問に思っていました：

オブジェクトを削除してgccをコンパイラとして使用するとどうなりますか？

先週、競合状態がオブジェクトの二重削除につながるクラッシュを調査していました。

オブジェクトの仮想デストラクタを呼び出すときにクラッシュが発生しました。これは、仮想関数テーブルへのポインタがすでに上書きされているためです。

仮想関数ポインタは最初の削除によって上書きされますか？

そうでない場合、その間に新しいメモリ割り当てが行われない限り、2番目の削除は安全ですか？

なぜ以前に問題が認識されなかったのか疑問に思っています。唯一の説明は、最初の削除中に仮想関数テーブルがすぐに上書きされるか、2番目の削除がクラッシュしないことです。

（1つ目は、「競合」が発生した場合に常に同じ場所でクラッシュが発生することを意味します。2つ目は、競合が発生しても通常は何も発生しません。その間に3番目のスレッドが削除オブジェクトを上書きした場合にのみ、問題が発生します。 ）。

編集/更新：

テストを行いましたが、次のコードがsegfault（gcc 4.4、i686、amd64）でクラッシュします。

「仮想」をdtorから削除すると、ダブルフリーが検出されるため、プログラムはglibcによって中止されます。'virtual'を使用すると、仮想関数テーブルへのポインタが無効であるため、デストラクタへの間接関数呼び出しを実行するとクラッシュが発生します。

amd64とi686の両方で、ポインターは有効なメモリ領域（ヒープ）を指していますが、そこにある値は無効です（カウンター？非常に低い、たとえば0x11、0x21）ので、コンパイラーの場合は「呼び出し」（または「jmp」） return-optimizationを実行しました）無効な領域にジャンプします。

プログラム受信信号SIGSEGV、

セグメンテーション違反。0x0000000000000021

の ？？（）（gdb）

#0 0x0000000000000021 in ?? （）

#1 0x000000000040083e in main（）

したがって、上記の条件では、仮想関数テーブルへのポインタは常に最初の削除によって上書きされるため、クラスに仮想デストラクタがある場合、次の削除はニルヴァーナにジャンプします。

私たちはインメモリ HSQLDB データベースに対して grails 統合テストを実行することに慣れていましたが、データが失われたため、障害点での調査は困難でした。物理データベース (postgres) に対してテストを実行するように移行しました。テストに合格すると、すべてがうまくいきます。テストが失敗した場合はいつでも、テストが失敗した理由に関する事後分析のためにデータをデータベースにコミットする必要があります。

要約すると、テストが成功する限りテストをロールバック モードで実行して、1 つのテストが他のテストに影響を及ぼさないようにし、テストの最初の失敗時にその時点でデータをコミットして停止するようにします。

私たちは統合テストの失敗を調査するのにかなりの時間を費やしており、調査のためにデータベースに保存されたデータを使用して最初の統合テストの失敗を停止するオプションが grails にあるかどうかを知りたいと考えています。少し検索しましたが、適切なポインターが見つかりませんでした。統合テストをトラブルシューティングするために他の方法に従っている場合、および共有する価値がある場合はお知らせください。

デバッグセッションで、残念ながらゴミを指しているアドレスがあるとします。そして、その周りの記憶を調べて、近くに何があるかを調べたいと思います。予想通り、次のエラーが発生します。

では、問題は次のとおりです。アドレスの範囲を読み取る方法はありますか?その一部は有効ではありませんか?

$t5+n(より正確には、上記の例で有効なアドレスがあることをどのように知ることができますか0 < n <= 64?)

クラッシュダンプを見ています。一部の変数はwindbgで完全に表示できるように見えますが、他の変数は単に「メモリアクセスエラー」と表示されます。これは何が原因ですか？一部の変数には意味のある値があり、他の変数には単にリストされているのはなぜですか?

すべての問題は、次のポインターに関連付けられているようです。これらのポインターの多くは初期化されていませんが、それらの大部分は有効な場所を指しているはずです。このクラッシュの性質 (単純な null ptr デリファレンス) に基づいて、プロセス全体が昼食に出ていないことはかなり確信しています。

通常、この問題をどのように回避しますか？Computer1のlibcコード（システム共有ライブラリ）内でスレッドがクラッシュし、コアダンプが生成されると想像してください。ただし、このコアダンプが分析されるComputer2には、異なるバージョンのlibcが含まれている可能性があります。

それで：

1. リモートコンピュータに同じ共有ライブラリを配置することはどれほど重要ですか？gdbは、Conputer2にまったく同じバージョンのlibcがなくても、スタックトレースを正しく再構築しますか？

2. libcの正しいデバッグシンボルを持つことはどれほど重要ですか？Computer2にまったく同じデバッグシンボルがなくても、gdbはスタックトレースを正しく再構築しますか？

3. そして、共有システムライブラリのこのデバッグシンボルの不一致の問題を回避するための「正しい」方法は何ですか？私にとって、この問題をエレガントな方法で解決する単一の解決策はないように思われますか？多分誰もが彼の経験を共有することができますか？

WindowsのC++アプリケーションでメモリリークを追跡しようとしていますが、リークされたオブジェクトが多数あるアプリケーションのメモリダンプがあります。私はWindbgを使用して、次のようにしてそれらを追跡しています。

これは次のことを示しています。

したがって、ヒープ003d0000にリークしているオブジェクトが含まれていることがわかります。そのため、次を使用します。

これは次のことを示しています。

したがって、98バイトのサイズのオブジェクトのリークがあり、そのオブジェクトが何であるかを追跡できます。

これは次のことを示しています。

これは、Windbgに関する私の知識が不足している場所です。ヒープ上のオブジェクトはクラスのものであることMyObjectがわかりますが、このオブジェクトが作成された場所を確認するにはどうすればよいですか？

どんな助けでも大歓迎です！

ありがとう、J

サーバーでWCFサービスを実行していますが、ときどき（毎月1〜2回）、「不明なエラー（0x8005008）」という情報メッセージとともにCOMExceptionがスローされます。この特定のエラーをグーグルで検索したところ、IISで仮想ディレクトリを作成する際の問題に関するスレッドしか得られませんでした。また、ソースコードには、IISで仮想ディレクトリを作成することとは何の関係もありません。

WinDBGでさらに分析するために例外をキャッチしたときに、メモリダンプを取得しました。正しいスレッドに切り替えた後、！CLRStackコマンドを実行しました。

私の結論は、コードが System.DirectoryServices.PropertyCollection.get_Item（System.String）を呼び出しているときに失敗するということです。

したがって、！CLRStack -aを発行した後、次の結果が得られます。

私の最初の質問は、なぜプロパティ名にデータが表示されないのかということです。Windbgはちょっと新しいです。ただし、= 0x0000000001dcef78でdumpobjectを実行しました：

そのため、ソースコードがActive Directory（永続層に使用されるもの）からpersonalprescriptioncodeをフェッチしようとすると、失敗します。スタックを振り返ると、Copyメソッドを発行するときです。 DirectoryServiceLib.LdapProvider.DirectoryPost.Copy（DirectoryServiceLib.LdapProvider.DirectoryPost）

したがって、ソースコードを調べます。

このコードは、同じUserIdを持つOU = limboで別の投稿を探しており、見つかった場合は、属性を新しい投稿にコピーします。この場合、それは実行され、personalprescriptioncodeで失敗します。OU =Limboの下のActiveDirectoryを調べましたが、属性personalprescriptioncode=31243の投稿がそこにあります。

質問1：一部のパラメータとローカルのデータが表示されないのはなぜですか？メモリダンプが作成される前にクリーンアップしたのはGCですか。

質問2：この問題の解決策にたどり着くためにできることはもうありますか？

初めて DebugDiag を使用していますが、Windows 7 x64 で使用しています。(x86) myprogram.exe のクラッシュ ルールを作成しました。これは、意図的に「不明な例外 (0xc0000417)」でクラッシュするようにコーディングしたため、クラッシュすることが保証されています。

ミニダンプをキャプチャするように構成されたウィンドウの「起動と回復」があります。できます。カスタム ミニダンプをキャプチャするようにレジストリ エントリを調整しました。できます。はい、結果として 2 つの異なるダンプ ファイルを取得しています。私は大丈夫です。

しかし、私の理解が正しければ、クラッシュ ルールがトリガーされたときに DebugDiag は単純に「生き返る」べきですが、クラッシュが発生したときに DebugDiag は何もしません。DebugDiag は、dmp ファイルを手動で明示的にロードした場合にのみ分析を提供します。ルールを自動トリガーするにはどうすればよいですか?

例外をキャプチャした .Net アプリケーション ダンプがあります。windbg を使用して分析しており、メソッドの 1 つで String パラメータの値に関心があります。String オブジェクトを分離しました。私のwindbgの作業は次のとおりです。

m_stringLength メンバー変数は、文字列の長さが 179 文字であることを示していますが、文字列を調べると、長さは 32 文字しかないようです。この文字列のメモリを見ると、NULL で終了しているように見えます。NULL 終了文字の後にさらに文字があります。これはメモリの再利用または文字列の破損である可能性がありますが、表示されているパスは正しいように見えます。スローされる例外は「パスに無効な文字」ですが、このパスには無効な文字はありません。したがって、この例外のコール スタックは次のようになります。

System.IO.Path.CheckInvalidPathChars メソッドは、m_stringLength で見つかった長さを使用して文字列を処理しますか、それとも文字列自体の NULL 終端を考慮しますか? また、私が見つけられなかった何かを見つけることができれば、他に何か問題があるという事実にもオープンです。