問題タブ [pageheap]

次のいずれかのメッセージで最終的にクラッシュするソフトウェアをデバッグしています。

このソフトウェアは非常に古いものですが、現在変更することはできません。Visual C++ 6.0 で書かれています。ある種のバッファ オーバーフローであると推測しているため、どこで発生しているかを検出する方法を見つけようとしています。

PageHeap (私が欲しいものを教えてくれるようです) とGFlagsに関する情報を見つけましたが、それを機能させることができないようです。

テストプログラムを作成しました：

エラーが発生します：

次に、次のコマンドを実行して PageHeap をアタッチしようとしました。

その後、(Visual C++ 6.0 インターフェイスと Windows エクスプローラーの両方を使用して) 再実行すると、同じエラーが発生しました。

次に、リリース バージョンをコンパイルして、Visual C++ 6.0 インターフェイスを介して実行すると、次のエラーが発生しました。

そして、Windows エクスプローラーから、エラー レポートを送信するように求める Windows ダイアログが表示されました。

私は何が欠けていますか？

ページヒープの破損を追跡するために、Pageheapを有効にしてgflagsを使用してアプリケーション（VC MFC）を実行しています。

アプリケーションがクラッシュし、このエラーが表示されたため、これらの行を解釈できませんでした（リソースが利用できないと感じることを除いて）

誰かがアプリのクラッシュを引き起こした正確な理由に光を当てることができますか？

（情報：アプリケーションは、マルチプロセッサマシンで実行されている約500スレッドのマルチスレッドアプリケーションです）

ヒープの破損を特定するために PageHeap を使用しています。アプリケーションのヒープが破損しています。ただし、メソッドに渡された文字列の stl オブジェクトを作成すると、アプリケーションが (クラッシュにより) 中断します。クラッシュ場所の近くに目に見えるメモリの問題は見られません。ヒープの破損を検出するためにフル ページ ヒープを有効にし、スタックの破損を検出するために /RTC を有効にしました。

ヒープの破損が発生した正確な場所でブレークするにはどうすればよいですか?

以下のコードピースの2番目と3番目のステートメントを実行しているときに、Pageheapによってアプリケーションが強制的にクラッシュすることを期待していました。しかし、これは起こっていません。アプリケーションのフルページヒープを有効にしました。

2番目と3番目のステートメントでアプリケーションを壊すためにページヒープを作成するには、どのような追加の操作を行う必要がありますか？

しかし、私が使用する場合、次のステートメントのページブレークは私のアプリケーションを壊します

アプリケーションが次のエラーでクラッシュします。

アプリケーションの完全なページ ヒープを有効にしました。アプリケーションがランダムな場所でクラッシュします。多くの場合、クラッシュの場所はSTLの内部です。いずれの場合も、コールスタックが破損しているようです。

アプリケーションは、ライブラリと DLL ファイルのリストを使用します。すべての DLL ファイルとライブラリは、マルチスレッド DLL ライブラリ (コマンド ライン オプション/MD) を使用してビルドされます。

ライブラリの 1 つは、ヒープにメモリを割り当てるためにHeapAllocメソッドを使用しています。

クラッシュを特定するには、どのような手法を使用すればよいですか?

私は過去4年間、ヒープの破損をデバッグするためにpageheapを使用しました。一般的には問題ありません。しかし今、私は奇妙な行動に直面しています。次のフラグを含むグローバルフラグを使用して、win7-sp1-x86ホストでプロセスのページヒープを有効にした後：-ヒープテールチェックを有効にする-ヒープフリーチェックを有効にする-ページヒープを有効にする

メモリ不足の例外でクラッシュすることに気づきました。！address -summaryコマンドは、仮想メモリの約90％がPageHeapによって消費されたことを示しています。

私が知っているように、ページヒープがそのような大量のメモリオーバーヘッドにつながるべきではないので、それは私にとって本当に奇妙です。

誰かがそのような行動の理由を説明してもらえますか？

1. バグのコード

   /li>

2. Visual Studio 2010のプロジェクトメニューから、ビルドが「リリース」および「x64」（マシンはx64）であることを確認しました

3. フルページヒープを有効にする

   /li>

4. windbgをデフォルトのデバッガーにする

   /li>

5. cmdデバッガなしとは別のexeとしてコードを実行します

   出力：

   その後、windbgが破損をキャッチしているのが見られます。そして、フルページヒープは破損を即座にキャッチすることを想定していると思いました。

   なぜフルページヒープがダメなのかについてのコメントはありますか？

私のコードは次のようなものです：

config.ini のコンテキストは次のとおりです。

しかし、GetPrivateProfileString が呼び出されたとき、szValue のコンテキストは空です! そして、ページヒープを無効にすると、szValue のコンテキストは "daemon.dll" になります。また、フラグ (完全なトレース) を使用してページヒープを有効にすると、szVaule のコンテキストは "daemon.dll" になります。

API GetPrivateProfileString のバグはありますか?

ページ ヒープをオンにして Application Verifier でアプリケーションをテストしようとすると、問題が発生しました。「localhost」のような正当なホスト名であっても、gethostbyname API は常に失敗することが判明しました。この問題は、gethostbyname を使用した非常に単純なテスト アプリケーションでも試したすべての Win-7 または Server 2008 R2 で再現されます。

再現手順: appverifier で "page heap" と "UseLFGGuard..." チェックボックスをオンにし、gethostbyname(..) を使用して任意のアプリを実行します。

アプリケーション コードの例 (appverifier がオフの場合は「127.0.0.1」を出力し、appverifier がオンの場合は「getaddrinfo failed」を出力します):

最も珍しいことは、インターネットで何も見つけられなかったことです。これは既知の問題ですか? 回避策はありますか？

Microsoft のstrncat. ソース バッファを超えて 1 バイトに達します。次のコードを検討してください。

strncat112 バイト ブロックの後に 1 バイトを読み取ります。そのため、不運にも無効なページ境界に割り当てられると、アプリケーションがクラッシュします。大規模なアプリケーションは、そのような場所で断続的にクラッシュする可能性があります。(このような状態は、 gflags PageHeap設定でシミュレートできることに注意してください。適切な位置合わせのために、ブロック サイズはポインター サイズで割り切れる必要があります。)

これは予想される動作ですか、それともバグですか? それを確認するリンクはありますか？（いくつかの説明を読みstrncatましたが、最初の心構えに応じて両方の方法で解釈できます...）

更新（証拠に関する質問に答えるために）：上記のテキストから明らかでない場合は申し訳ありませんが、これは実験的な事実です. strncatアドレス src+srcBufSize の読み取り時に、アプリケーションで断続的なクラッシュが発生します。この小さな例では、クラッシュ時にgflags PageHeapを使用して実行すると、一貫して (100%) 再現されます。私が見る限り、証拠は非常にしっかりしています。

Update2 (コンパイラに関する情報) MS Visual Studio 2005 バージョン 8.0.50727.867。ビルド プラットフォーム: 64 ビット リリース (32 ビットの再現なし)。クラッシュの再現に使用された OS: Windows Server 2008 R2。

Update 3この問題は、MS Visual Studio 2012 11.0.50727.1 でビルドされたバイナリでも再現されます。

Update 4 Microsoft Connect の問題へのリンク。MSDN フォーラムのディスカッションへのリンク

Update 5この問題は、次の VS リリースで修正される予定です。古いバージョンの修正は予定されていません。上記の「Microsoft Connect」リンクを参照してください。