問題タブ [pageheap]
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.
debugging - ページ ヒープは有用なスタック情報を記録しませんか?
通常のページ ヒープ (いっぱいではない) を使用して (分離されたテスト アプリで) クラッシュ シナリオをテストしようとしています。
フラグを設定しました
そして、整数バッファを1つの要素で上書きしています
実際、ブロックがベクトル d'tor で解放されると、休憩が取れます。ブレークのコールスタックは正しく報告されます:
ただし、障害のある割り当てを見ると、次のようになります。
つまり、割り当てスタック トレースがありますが、明らかにまったく役に立たないところで止まりますRtlAllocateHeap
。
メモリ内のスタック トレースを見ると、次のようになります。
実際にはそれ以上の記録はないようです。
有用なスタック トレースを記録するようにページ ヒープを修正するにはどうすればよいですか?
Test プロジェクトはFPO (/Oy) でコンパイルされていないRtlAllocateHeap
ことに注意してください。FPO の影響を受けるとは予想していませんでした。
更新:手動で割り当てにステップインして、問題の呼び出しの FPO 性を確認しました (以下を参照) 。VC80(VS2005) ランタイム ライブラリmalloc
と同様に、何らかの形式の FPO が有効になっているように見えます。op new
おそらく、ページ ヒープのスタック DB のスタック トレースが台無しになっている可能性があります。
com - SHGetFileInfo は、SHGFI_ICON の使用時にヒープ破損を引き起こす
テスト中のプロセスでページ ヒープを有効にすると、SHGetFileInfo が呼び出されたときにヒープの破損が発生したことを示すアクセス違反がトリガーされます。
コール スタックの一番上には msvcr90!wcspbrk が表示され、さらに下に進むと、SHGetFileInfo を呼び出す shell32 に到達するまで、ole32 内の COM 関連のアイテムが表示されます。
私がオンラインで見つけたものによると、shell32 を使用した奇妙さの一般的な問題は、最初に CoInitialize/CoInitializeEx を呼び出さないことですが、この時点で CoInitializeEx() は既に呼び出されており、以下のコードの直前に呼び出すと S_FALSE が返されます。
以下のコードは、.NET から PInvoked された DLL 内にあります (コードは、特定のファイルに使用されるアイコンを取得するために使用されます)。
(ここで、logfile.txt はルート ドライブ上のランダム テキスト ファイルです)
簡単にするために、最初のパラメーターをマシン上のファイルにハードコードしました。
64 ビット Windows OS を使用していますが、コードは 32 ビット コンテキストで実行されます。SHGetFileInfo のナロー バージョンを使用すると、同じ結果が得られます。
プロセスのページ ヒープを無効にしても問題はありません。
フラグ SHGFI_ICON を使用しない場合、問題は発生しません。
編集: @HansPassant は、再現可能なサンプルを追加するよう要求しました。これは、問題を示す Visual Studio 2010 Win32 コンソール アプリケーションへのリンクです:サンプル
c++ - Visual Studio 2015 でのデバッグが遅い -- ページ ヒープをオフにできませんか?
Visual Studio 2015 を実行していますが、これまでデバッグで問題が発生したことはありません。ただし、最近のデバッグは非常に遅いです。また、Microsoft Visual C++ ランタイム ライブラリから「ヒープ破損が検出されました」というヒープ デバッグ エラーが発生し始めました。ヒープ バッファの終了後にアプリケーションがメモリに書き込んでいるエラーを修正しますが、これらのエラーをスローするコードを実行していない場合でも、デバッガは非常に遅くなります。ヒープチェック設定がオンになっていると思いますが、オフにしたいと思います。
デバッグ出力ウィンドウの上部に 2 つの行があり、それぞれPage heap: pid 0x530: page heap enabled with flags 0x2.
に、これが問題の原因であるか、少なくとも関連していると考えています。ページ ヒープをオフにできません。gflags GUI で試して (何もチェックされていませんでしたが、チェックしてチェックを外してみました)、コマンド ラインで試しました。VSを再起動し、コンピューターを再起動し、VSをアンインストールして再インストールしました...何も機能しません。
VS でリリース構成を実行すると、まだ遅く、出力ウィンドウの上部にページ ヒープ メッセージが表示されます。ただし、ヒープ デバッグ エラー メッセージが表示される代わりに、アプリケーションがフリーズするだけです。しかし、ページ ヒープ メッセージを見ると、これは VS 以外の問題であり、デバッグ構成とは関係ないと思われます。
編集: wxWidgets 3.1 を使用していますが、ファイルを開く、textCtrl に多くの行を出力するなど、wxWidgets 関連のイベント中にプログラムの実行が最も遅くなることに気付きました。これが関連しているかどうかはわかりません。