fatal error VC++

Version imprimable

06/04/2011, 16h57
koukou11

fatal error VC++
Bonjour, je travaille sous vc++ avec MFC (j'utilise l'allocation dynamique).
j'ai l'erreur:

Citation:

"fatal error LNK1000: Internal error during IncrBuildImage"

et parfois j'obtiens" Memory leak detect"
Je ne sais pas si ces deux erreurs sont équivalentes.

j'ai déja dans chaque fichier .cpp le code suivant:
Code:

1 2 3 4 5 6 #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif
alors j'obtiens a la fin du débogage le fichier .cpp et la ligne qui contient le memory leak . mais je n'arrive pas à cerner l'erreur pour la résoudre

Par exemple:

Citation:

Detected memory leaks!
Dumping objects ->
c:\users\koukou\desktop\client-serveur\serveur_application mfc\serveur\serveur\envoireception.cpp(29) : {107} normal block at 0x00745CD8, 12 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD
c:\users\koukou\desktop\client-serveur\serveur_application mfc\serveur\serveur\envoireception.cpp(25) : {105} normal block at 0x00747F38, 260 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
c:\users\koukou\desktop\client-serveur\serveur_application mfc\serveur\serveur\envoireception.cpp(22) : {104} normal block at 0x00747BF0, 780 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

voici les lignes correspondantes:
Code:

1 2 3 4 5 6 char* sendBuffer=new char[780]; LPBYTE byte_sendBuffer=new BYTE[260]; LPBYTE byte_recvbuffer=new BYTE[12];
J'ai bien vérifié qu'il n'y a pas un dépassement de mémoire allouée au niveau de mon code . je n'arrive pas à comprendre ou est le problème??
Merci pour l'aide
06/04/2011, 20h55
bacelar

Citation:

"fatal error LNK1000: Internal error during IncrBuildImage"

Citation:

et parfois j'obtiens" Memory leak detect"
Je ne sais pas si ces deux erreurs sont équivalentes.

Pas du tout.

L'une, c'est que LINK.EXE a planté, le motif le plus probable est l'utilisation erronée du paramétrage du linker ou du compilateur. Si ce problème est transitoire, je pense que des fichiers temporaires ne sont pas correctement mis à jour, pour la cause, voir la phrase précédente.

L'autre montre que vous ne faites pas correctement la gestion de la mémoire.
Et ce cas est si simpliste que je me demande comment on peut rester coincé avec.

Votre cours sur l'allocation dynamique parle du mot clé "new", c'est bien clair avec votre code, mais il existe aussi le mot clé "delete". http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Révisez votre cours, SVP.
06/04/2011, 22h01
koukou11
Citation:

L'une, c'est que LINK.EXE a planté, le motif le plus probable est l'utilisation erronée du paramétrage du linker ou du compilateur.

Si vous pouvez mieux clarifier s'il vous plait

Citation:

Votre cours sur l'allocation dynamique parle du mot clé "new", c'est bien clair avec votre code, mais il existe aussi le mot clé "delete".

j'utilise déja delete au niveau du destructeur de la classe, ce n'est pas ca le probleme
Code:

1 2 3 4 if(sendBuffer!=NULL) delete[](sendBuffer); if(byte_sendBuffer!=NULL) delete [](byte_sendBuffer); if(byte_recvbuffer!=NULL) delete[](byte_recvbuffer);
07/04/2011, 00h50
bacelar

Citation:

Citation:

L'une, c'est que LINK.EXE a planté, le motif le plus probable est l'utilisation erronée du paramétrage du linker ou du compilateur.

Si vous pouvez mieux clarifier s'il vous plait

C'est pour quelle version de VS ?
Si c'est pour VS2008, il y a un Hotfix :
http://support.microsoft.com/kb/948127
https://connect.microsoft.com/Visual...wnloadID=11399
Si c'est sous VS2010, pouvez-vous nous donner la liste des réglages du compilateur et du linker ne correspondant pas aux valeurs par défaut liées à la compilation incrémentielle ?

Citation:

j'utilise déja delete au niveau du destructeur de la classe, ce n'est pas ca le probleme

Vérifiez que votre destructeur est bien appelé et qu'il passe bien par ces lignes, une exception est si vite arrivée. :aie:

De plus, la vérification de la mémoire est faite par l'appel à la fonction

Code:

_CrtDumpMemoryLeaks();

qui est appelée très vraisemblablement en fin de "main", hors les variables globales ne sont pas encore désallouées à ce moment là.
Ces buffers ne feraient-ils pas partie d'une bien laide variable globale ?

N.B.: il est inutile de vérifier qu'un pointeur est à NULL avant d'appeler delete.
http://en.wikipedia.org/wiki/Delete_(C%2B%2B)
07/04/2011, 23h39
koukou11

Pour la version du VS c'est 2008. Merci cette erreur a disparu.

Pour le Memory leak:
je travaille avec une application MFC et ces buffeurs sont déclarés au niveau du constructeur de la classe associé à la boite de dialogue

Je ne sais pas exactement ou je dois appeler le destructeur de cette classe à moins qu'il soit appelé automatiquement lors de la fermeture de la boite de dialogue?

dans ce cas ou je dois appeler la fonction _CrtDumpMemoryLeaks()?
Excusez-moi si mes questions sont bêtes mais je suis débutante avec les MFC
08/04/2011, 02h03
bacelar
Citation:

Envoyé par koukou11

Excusez-moi si mes questions sont bêtes mais je suis débutante avec les MFC

J'ai l'impression que vous êtes tétanisée par les MFC, mais un programme MFC, c'est comme un programme C++ standard avec des classes en plus et des wizards dans VS qui vous mâche le travail en générant des kilotonnes de code, mais que vous pouvez lire sans aucun problème, vu que se n'est que du C++.
Donc pas de panic.

Dans une application type Dialog MFC, le wizard a généré, à la création du projet, 2 classes bien distinctes.

L'une dérivant de "CDialogEx" que vous semblez avoir bien localisé, car il semble que c'est dans cette classe que vous ajoutez ces buffers.(

Citation:

au niveau du constructeur de la classe associé à la boite de dialogue

)

La seconde classe, elle, dérive plus ou moins indirectement de "CWinApp".

C'est cette deuxième classe qui est le vrai moteur de votre application.

Regardez le code de la méthode "InitInstance" de cette deuxième classe. Vous y verrez des lignes comme :
Code:

1 2 CxxxxxxxxxxxxxxxDlg dlg; m_pMainWnd = &dlg;
Ce code est le lieu de naissance de l'instance unique (singleton) de la première classe (classe associé à la boite de dialogue).

Et comme pour toute variable C++ n'utilisant pas l'allocation dynamique, son destructeur sera appelé à la sortie de son "scope", qui dans notre cas de figure est la fin de la méthode "InitInstance".

Si vous n'en n'êtes pas sûr, vous n'avez qu'à mettre un point d'arrêt dans le code du destructeur de votre boîte de dialogue et vous verrez dans la callstack affichée par le débuggeur que c'est bien à cet endroit que le destructeur doit être appelé.

Si votre destructeur n'est pas appelé, en vérifiant cela avec des points d'arrêt dans le code du destructeur, c'est que vous fermez votre application MFC des plus salement.

Citation:

je dois appeler le destructeur

Non, c'est totomatique, si vous laissez votre application se fermer normalement.

Citation:

à moins qu'il soit appelé automatiquement lors de la fermeture de la boite de dialogue

Non, ce n'est pas à la fermeture de la boîte de dialogue mais à la sortie du scope de la variable locale "dlg" de la méthode "InitInstance" de la classe dérivant de "CWinApp".

Citation:

ou je dois appeler la fonction _CrtDumpMemoryLeaks

Un projet MFC, en DEBUG, l'appel automatiquement en sortie du WinMain (oui, oui, il y a aussi un WinMain dans une application MFC, mais il est bien caché des les fichiers des MFC).
Pour être précis, c'est une version simplifiée de CrtDumpMemoryLeaks qui est appelé. Vous pouvez la jouer ceinture et bretelle, en appelant _CrtDumpMemoryLeaks, avec toutes les options de mise en forme nécessaires, dans la méthode "ExitInstance" de la classe dérivant de CWinApp. A ce stade, le destructeur de la variable "dlg" a déjà été appelé et il ne devrait donc pas avoir de détection de fuite.

Il est donc probable que vous ne laissez pas se fermer correctement votre application MFC.

Merci bien pour les clarifications.Si je vous ai bien compris, j'ai cerné mon problème:
j'ai ajouté (en plus des 2 classes par défaut) une nouvelle boite de dialogue avec sa classe correspondante (héritant de CDialog) .
mais je n'ai pas mis la déclaration de l'objet de cette classe dans InitInstance (de la classe par défaut ) car l'idée est la suivante:

l'ouverture de cette nouvelle boite de dialogue dépend du traitement effectué au niveau de la première boite de dialogue, autrement dit c ca:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 void CServeurDlg::OnBnClickedOk() { bool acceptation=true; while(acceptation) { acceptation=theApp._communicationTCPServeur.AcceptConnection(); //MessageBoxA("accept(): erreur ","Connexion Error",MB_OK); } MessageBoxA("Connexion établie","Connexion",MB_OK); //ouverture de la nouvelle boite de dialogue EnvoiReception envoi_reception_Dlg; envoi_reception_Dlg.DoModal(); OnOK(); }
et c'est dans le constructeur de la classe "EnvoiReception" que j'ai déclaré les buffeurs , donc le destructeur "~EnvoiReceptionne" ne sera pas appelé automatiquement dans ce cas. Alors que faire? Merci

08/04/2011, 23h59
bacelar
Citation:
Code:

1 2 3 4 5 //ouverture de la nouvelle boite de dialogue EnvoiReception envoi_reception_Dlg; envoi_reception_Dlg.DoModal(); OnOK(); }
Citation:

donc le destructeur "~EnvoiReceptionne" ne sera pas appelé automatiquement dans ce cas

Et bien si, le destructeur sera automatiquement en fin de scope de la variable "envoi_reception_Dlg", c'est à dire à la fin de la méthode "OnBnClickedOk".

Utilisez le débuggeur de VS et des points d'arrêt dans le destructeur de la classe "EnvoiReception". Vous devez vos arrêter sur ces point d'arrêts aux moment ou vous sortirez de la méthode "OnBnClickedOk".

Mais si vous avez d'autres problèmes, avant la libération de ces buffers (via delete), dans le destructeur, vous ne passerez pas par les instructions delete.

N'hésitez pas à utiliser le debuggeur de VS quand vous avez un doute.