1

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

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

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

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

kernel32!RaiseException+53 
msvcrt!_CxxThrowException+36 
mfc42u!AfxThrowResourceException+19 
mfc42u!AfxRegisterWndClass+ab 
mfc42u!CAsyncSocket::AttachHandle+5c 
mfc42u!CAsyncSocket::Socket+25 
mfc42u!CAsyncSocket::Create+14
4

3 に答える 3

6

この同じ問題が私を狂わせましたが、最終的に修正して機能しています。これは MFC ソケット ライブラリのバグで、[メイン アプリケーション スレッド以外の] スレッド内で次のようなことをしようとすると、

CSocket socket;
socket.Create();

未処理の例外がスローされます。これに関する記事を見つけましたMicrosoft のコメントを参照してください

それはマイクロソフトから何かを言いましたが、それも私を助けませんでした. だからここに私が見つけた回避策があります。それが私のような欲求不満の人の助けになることを願っています.

内側のスレッド、これを行います

CSocket mySock;
SOCKET sockethandle = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
mySock.m_hSocket= sockethandle;

その後、mySock.Create を呼び出さないでください。これは、ソケット ハンドルの割り当てによって既に作成されているためです。まだ試していないので、mySock.Attach(sockethandle) を使用できるかどうかはわかりません。

その後、Connectなどを直接呼び出すことができます。

ソケットの使用が終わったら、呼び出してはいけません。mySock.Close()むしろ呼び出しclosesocket(mySock.m_hSocket);てください。これにより、ソケット オブジェクトが解放されます。上記のケースでアタッチが機能する場合、ソケットを解放するときにここでデタッチを行う必要があると思います。

幸運を

于 2010-01-28T16:56:14.350 に答える
0

これが実際のヒープ破損の問題なのか、ページヒープで実行した結果としてプログラムがリソース制限に達しただけなのか疑問に思います。

正確な詳細は覚えていませんが、Pageheap を使用すると余分なメモリ オーバーヘッドが発生するため、Pageheap を有効にしない場合よりもはるかに早くメモリが不足する可能性があります。

500 個のスレッドを実行すると、それぞれに 1MB のスタックと、途中で動的に割り当てられたメモリがあります。

CAsyncSocket::AttachHandleAfxThrowResourceExceptionウィンドウを作成できない場合にトリガーされます。ページヒープが原因でシステムが飽和しているようです。

問題を再現するには、500 のスレッドを実行する必要がありますか? その数を少し減らすことができれば、より多くのリソースを利用できるようになるでしょう。

于 2009-07-18T20:46:29.850 に答える