IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter

MFC Discussion :

fatal error VC++


Sujet :

MFC

  1. #1
    Membre confirm�
    Inscrit en
    D�cembre 2010
    Messages
    98
    D�tails du profil
    Informations forums :
    Inscription : D�cembre 2010
    Messages : 98
    Par d�faut fatal error VC++
    Bonjour, je travaille sous vc++ avec MFC (j'utilise l'allocation dynamique).
    j'ai l'erreur:
    "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 : S�lectionner tout - Visualiser dans une fen�tre � part
    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:
    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 : S�lectionner tout - Visualiser dans une fen�tre � part
    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

  2. #2
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 503
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 503
    Par d�faut
    "fatal error LNK1000: Internal error during IncrBuildImage"
    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.

  3. #3
    Membre confirm�
    Inscrit en
    D�cembre 2010
    Messages
    98
    D�tails du profil
    Informations forums :
    Inscription : D�cembre 2010
    Messages : 98
    Par d�faut
    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

    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 : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
     
    if(sendBuffer!=NULL) delete[](sendBuffer);
     if(byte_sendBuffer!=NULL) delete [](byte_sendBuffer);
    if(byte_recvbuffer!=NULL) delete[](byte_recvbuffer);

  4. #4
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 503
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 503
    Par d�faut
    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 ?

    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.

    De plus, la v�rification de la m�moire est faite par l'appel � la fonction 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)

  5. #5
    Membre confirm�
    Inscrit en
    D�cembre 2010
    Messages
    98
    D�tails du profil
    Informations forums :
    Inscription : D�cembre 2010
    Messages : 98
    Par d�faut
    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

  6. #6
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 503
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 503
    Par d�faut
    Citation Envoy� par koukou11 Voir le message
    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.(
    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 : S�lectionner tout - Visualiser dans une fen�tre � part
    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.

    je dois appeler le destructeur
    Non, c'est totomatique, si vous laissez votre application se fermer normalement.

    � 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".

    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.

  7. #7
    Membre confirm�
    Inscrit en
    D�cembre 2010
    Messages
    98
    D�tails du profil
    Informations forums :
    Inscription : D�cembre 2010
    Messages : 98
    Par d�faut
    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 : S�lectionner tout - Visualiser dans une fen�tre � part
    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

  8. #8
    Expert confirm�
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    F�vrier 2005
    Messages
    5 503
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 53
    Localisation : France, Val de Marne (�le de France)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : F�vrier 2005
    Messages : 5 503
    Par d�faut
    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    //ouverture de la nouvelle boite de dialogue
       EnvoiReception envoi_reception_Dlg;
       envoi_reception_Dlg.DoModal();
       OnOK();
    }
    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.

Discussions similaires

  1. erreurs fatal error C1010 dans visual c++ 6.0
    Par screeminelle dans le forum MFC
    R�ponses: 2
    Dernier message: 12/10/2005, 13h30
  2. Fatal error: Allowed memory size of...
    Par Webfab dans le forum Langage
    R�ponses: 3
    Dernier message: 17/09/2005, 10h11
  3. R�ponses: 17
    Dernier message: 28/07/2005, 08h20
  4. Fatal Error : OpenGL GLX extension not support
    Par kacedda dans le forum GLUT
    R�ponses: 5
    Dernier message: 06/06/2005, 10h28
  5. class php5 - Fatal error: main() [function.main]
    Par tom261285 dans le forum Langage
    R�ponses: 3
    Dernier message: 21/01/2005, 14h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo