問題タブ [umdh]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
665 参照

c++ - DebugDiag コール スタックがコール スタック内の関数の行番号を表示しない

Windows のネイティブ コードでメモリ リークを分離しようとしています。

テスト ケースを複数回実行し、プロセスに DebugDiag をアタッチして、疑わしいリークに関する情報を収集しました (メモリ リークは、PerfMon で複数回実行して確認しました)。

DebugDiag は、次のような疑わしいコール スタックを指摘しました。

シンボルを適切に構成しましたが、コール スタックからさらに情報を抽出する方法を知りたいと思いました。

  1. UMDH ログには、差分ログにも (ファイル名と共に) 行番号があります。ただし、DebugDiag レポートでは、これらの関数の行番号が見つかりません。関数が非常に長い場合、行番号なしでコール スタックを見るだけではコンテキストを説明することが難しくなります。DebugDiag ログから関数 (ファイル) の行番号を抽出する方法はありますか?

  2. 私が知りたかったもう 1 つのことはmodule!function、コール スタック内の各エントリの 16 進オフセットの重要性です。

  3. コール スタックの割り当てサイズは? このコールスタックの実行ごとに解放されていない割り当てられたメモリ (したがってリーク) ですか?

  4. DebugDiag 機能に関する包括的なドキュメントへのポインタはありますか?

0 投票する
0 に答える
153 参照

c++ - umdh.exe は、特定のスタックの割り当ての一部のみを表示します

umdh.exe を使用してメモリ リークをトラブルシューティングする方法を学ぼうとしています。それを行うために、サンプルアプリを作成しました:

コンパイル済み (リリース)、構成済みの umdh.exe:

  1. set _NT_SYMBOL_PATH= http://msdl.microsoft.com/symbols/download;C :\TestProjects\HelloWorld\x64\Release;
  2. gflags.exe /i HelloWorld.exe +ust

次に、実験を行いました:

  1. HelloWorld.exe 10000 1000
  2. 止まるまで待った @ 最初の getchar
  3. umdh.exe -pn:helloworld.exe -f:c:\first.log
  4. 実行を継続し、停止するまで待機 @ second getchar
  5. umdh.exe -pn:helloworld.exe -f:c:\second.log

私が気付いたのは、100回の割り当てであろうと1000回の割り当てであろうと、呼び出すパラメータに関係なく、first.logとsecond.logが非常に似ていることです(実験が異なるため)。

  1. umdh.exe -dc:\first.log c:\second.log -f:c:\result.log

そして、予想される1000ではなく、 17 個の allocsを持つ唯一のスタックを取得します。

更新: TaskProcess は、プライベート バイトとコミット サイズの両方が期待値で増加することを示しています。

UPDATED2: DebugDiag は、10000 の割り当てと正しい場所を指しているいくつかのサンプリングされたコール スタックでリークを正しく示します。

私が間違っていることは何か分かりますか?

ありがとうございました!

0 投票する
0 に答える
65 参照

pointers - 配列へのポインターと UMDH ログの削除

C# および C++ で記述されたアプリケーションのメモリ リークを調査していました。PerfMon ログと WinDbg/SOS デバッグを使用していくつかの C++ コンポーネントに分離したら、UMDH (+ust で有効化された gflags) を使用してスナップショットを比較し、どのヒープ割り当てがメモリをリークしているかを見つけようとしました。

最後に、コードの手動レビューによってリークが発見されました。以下のサンプル コード スニペット。

なぜUMDHがこれをキャッチしなかったのか疑問に思っていましたか? UMDH は、これを比較ログの問題として報告していません。WinDbg ヒープ コマンドは、リークを指摘するのに役立ちましたか?

0 投票する
1 に答える
173 参照

working-set - リソース モニターで報告されたメモリが UMDH に表示されない

時間の経過とともにサーバーメモリを断続的に使い始め、解放するために再起動する必要があるサービスがあります。gflags で +ust をオンにし、サービスを再起動して、スケジュールされた UMDH スナップショットの取得を開始しました。問題が再発したとき、リソース マネージャーはワーキング セットとプライベート バイトで複数の GB を報告しましたが、UMDH スナップショットは、プロセスのヒープ内の数 MB の割り当てしか占めていません。

UMDH スナップショット ファイルの上部に、「ヒープ マネージャーがスタックを収集した割り当てのみがダンプされます」と記載されています。
+ust フラグが指定されたときに、プロセス内の割り当てがトレースなしになるのはどうしてですか?

これらの GB がどこにどのように割り当てられたかを確認するにはどうすればよいですか?

0 投票する
1 に答える
672 参照

windows - UMDH がコール スタックを提供しない

UMDH(x64) を使用してメモリ リークをテストしています。私のコードは FPO に最適化されておらず、カスタマイズされたアロケーターも使用していません。「new」演算子のみを使用します。

テスト中のイメージの Gflags(x64) で「ユーザー モード スタック トレース データベースの作成」が有効になっています。

非リーク ケースとリーク ケースの両方で UMDH を使用してアプリケーションを追跡し、両方のケースでログを取得しました。

ログを UMDH と比較しました。上部のコメント行から明らかなように、正しい pdb が選択されています。

問題:

コール スタックにコードのスタックが表示されません。一般的な Windows 関数名をトレースするだけです。x64 でデバッグ バージョンとリリース バージョンの両方を試しました。何か不足していますか?

得られたコードと差分トレースは次のとおりです。