2010-02-06 3 views
0

J'ai une application qui utilise winsock. La partie d'E/S est gérée sur un autre thread. Et j'utilise la méthode de sélection de blocage pour les sockets. Mais le point est que, après 5-6 heures, mon application donne l'exception 0xC00000FD, à la ligne de la fonction de sélection. Pour autant que je sache, cette exception se produit lorsqu'il y a récurrence, ou de très grandes variables locales. Mais aucun d'eux n'est le cas pour moi.Exception de dépassement de pile (0xC00000FD) à la fonction de sélection winsock

Alors, avez-vous une idée de la raison pour laquelle je reçois cette exception? Ou des idées pour découvrir ce qui cause réellement l'exception?

merci beaucoup

EDIT 2:

Bonjour à tous, je suis désolé, mais depuis reproduire le cas prend beaucoup de temps, je viens de réaliser que cela n'a pas résolu le problème. Tout semble correct lorsque l'exception de dépassement de pile se produit sur la ligne de la fonction de sélection. Je veux dire qu'il s'agit d'une socket serveur avec un client connecté. Donc il y a 2 socket dans rset et 1 dans wset. Après la sélection, je vérifie toutes les douilles prêtes et fais le nécessaire, lis, écris, accepte. Le délai d'attente est de 250 ms. Pensez-vous que cela puisse être le problème? Je ne veux pas que cette fonction soit bloquante, donc elle n'est pas nulle. Mais quelle sera la différence exacte si j'utilise {0,0}

Un indice important est:
Même code fonctionnait sans problème, quand socket client n'a pas l'envoi de données. Mais lorsque j'ai commencé à envoyer des données du client au serveur, ce problème est survenu.
Je suis sûr qu'il n'y a pas de problème avec FD_SETs et FD_CLR, je veux dire quand le client n'envoyait pas seulement 1 socket (serveur) était dans rset et 1 (client) était dans wset.

De toute façon j'ai regardé beaucoup d'échantillons, mais il semble qu'il n'y ait pas de différence.

S'il vous plaît voir ci-dessous les variables locales capture d'écran (j'ai supprimé le nom de l'exécutable, car il est un produit commercial) http://img192.imageshack.us/img192/1948/stackoverflow.jpg

Et voici la pile d'appel: ntdll.dll 7c90df3a()
[Cadres ci-dessous peuvent être incorrectes et/ou manquant, pas de symboles chargés pour ntdll.dll] mswsock.dll! 71a53c9c()
ntdll.dll! 7c90d26c()
mswsock.dll! 71a55f9f()
mswsock.dll! 71a55974()
!ws2_32.dll 71ab314f()

de xyz.exe vm_socket_select (vm_socket * HDS = 0x04c1fb84, int nhd = 1, int masques = 7) Ligne 230 + 0x1b octets C
xyz.exe ND: :! nd_socket :: SocketThreadProc() ligne 173 + 0x12 octets C++
xyz.exe ND :: nd_socket :: ThreadRoutineStarter (void * u = 0x07d63f90) ligne 332 C++
xyz.exe _callthreadstartex() ligne 348 + 0x6 octets C
xyz.exe! _threadstartex (void * ptd = 0x011a3ce8) Ligne 326 + 0x5 octets C
kernel32.dll!7c80b713()

Je suis désolé. Un grand merci

+2

Pouvez-vous s'il vous plaît nous montrer le code? –

Répondre

3

Avez-vous essayé d'arrêter votre programme dans un débogueur après un certain temps? Ensuite, jetez un oeil à la pile, il pourrait vous donner un indice. La récursion ne signifie pas qu'une de vos fonctions s'appelle indéfiniment, elle ne peut pas être plus délicate et impliquer plusieurs couches avant qu'elle ne revienne là où elle a commencé.

+0

Ou regardez simplement la pile au moment de l'accident dans un débogueur. –

+0

oui mais cela prend 5 heures :) –

Questions connexes