2009-07-18 6 views
1

J'ai mon application (VC MFC) exécutée avec gflags avec Pageheap activé pour traquer la corruption de tas de page.CSocket :: Créer une exception de lancement dans mon application MFC

Maintenant, l'application est tombé en panne et il montre cette erreur, je ne pouvais pas interpréter ces lignes (autres que d'avoir une idée de inavailablity des ressources)

Quelqu'un peut-il jeter une lumière sur ce qui est la raison exactement qui a causé la crash de l'application?

(info: L'application est un multithread environ 500 threads en cours d'exécution, dans un environnement multi - machine à processeur)

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

Répondre

0

Je me demande si cela est votre problème de corruption de tas réelle, ou si votre programme vient frapper un limitation des ressources suite à l'exécution de Pageheap. Je ne me souviens pas des détails exacts, mais Pageheap entraîne un surcroît de mémoire, si bien que vous pouvez manquer de mémoire beaucoup plus rapidement que si vous n'aviez pas activé PageHeap. Avec 500 threads en cours d'exécution, vous disposez d'une pile de 1 Mo pour chacun d'eux, plus toute la mémoire allouée dynamiquement en cours de route. Déclenche AfxThrowResourceException si elle ne peut pas créer une fenêtre. Il semble que votre système soit saturé à cause de PageHeap.

Avez-vous 500 threads en cours d'exécution pour reproduire le problème? Peut-être que si vous pouviez réduire un peu ce nombre, il y aurait plus de ressources disponibles.

+0

Oui page tas exige plus de mémoire, mais ce que nous voulions est le point d'injection de corruption du tas. si nous faisons fonctionner notre appln dans cette condition chargée, l'application se bloque. Voici un autre point de plantage, de nombreux cas, il a planté dans cet endroit particulier, à condition que nous courons l'application dans une machine haut de gamme (8 core & 4 Go RAM) mfc42u! CFixedAlloc :: Alloc + 5c mfc42u! CString :: AllocBuffer + 25 mfc42u! CString :: CString + 3e WP_Communications_Server! CWPGenericService :: AddToMessageLog + b9 Une idée? nous sommes coincés dans ce problème pendant plus de 2 semaines. – buddingspacer

+0

Avez-vous besoin d'un plein Page, ou pourriez-vous essayer avec Normal, par http://support.microsoft.com/kb/286470? Étant donné que votre tas est corrompu, il risque de planter n'importe où. Vous n'avez jamais répondu à ma question. Y a-t-il une chance de réduire la quantité de threads en cours d'exécution pour conserver les ressources pendant le test? Ou le comportement n'augmente-t-il que lorsque 500 threads sont en cours d'exécution? –

4

Ce même problème m'a rendu fou mais finalement je l'ai réparé et cela fonctionne. Ceci est bogue avec la bibliothèque MFC socket que lorsque l'intérieur d'un fil [autre que le thread principal de l'application] Si nous essayons de faire quelque chose comme

CSocket socket; 
socket.Create(); 

Il sera lance une exception non gérée. J'ai trouvé un article dessus See What Microsoft says about this

qui a dit quelque chose de Microsoft mais cela ne m'a pas aidé non plus. Donc, voici une solution de contournement que j'ai trouvé et j'espère que cela peut aider un gars frustré comme moi.

intérieur fil, faites ce

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

Après que numéros de télécommunication exclus mySock.Create comme il a déjà été créée par l'affectation de la poignée de prise. Je ne suis pas sûr si nous pouvons utiliser mySock.Attach (sockethandle) comme je ne l'ai pas encore essayé. Ensuite, vous pouvez appeler Connect, etc. directement.

Lorsque vous avez terminé d'utiliser le socket, n'appelez PAS mySock.Close() - appelez plutôt closesocket(mySock.m_hSocket); et cela libérera l'objet socket. Si Attach travaille dans le cas ci-dessus, je suppose que nous devons faire Detach ici quand libérer le socket.

Bonne chance

+0

Si ce n'était pas pour votre poste ici, je n'aurais pas trouvé mon problème. J'essayais de faire fonctionner une ancienne application MFC en tant que service et je n'arrivais pas à comprendre pourquoi je ne pouvais pas appeler Create() et Listen() dans le service. J'étais sur la mauvaise voie et je pensais que c'était quelque chose à voir avec les privilèges d'accès au réseau, mais en fait cela avait à voir avec cela et le fait que CAsyncSocket a besoin d'une fenêtre. Attach() ne fonctionne toujours pas dans le service, mais au moins maintenant je sais d'où vient le problème. Je vais probablement écrire mes propres implémentations CSocket en utilisant WinSock. Merci un million! – jbx

Questions connexes