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 :

exception de premiere chance.. visual 2010


Sujet :

MFC

Vue hybride

eomer212 exception de premiere... 13/12/2010, 15h21
TheGzD N'as-tu fais un usage... 13/12/2010, 16h38
eomer212 creusons, creusons.. 14/12/2010, 19h40
TheGzD Il faudrait voir ton code... 15/12/2010, 10h11
eomer212 bon, ben voila.. 15/12/2010, 22h50
Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre très actif
    Profil pro
    Développeur indépendant
    Inscrit en
    Août 2004
    Messages
    374
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : Août 2004
    Messages : 374
    Par défaut exception de premiere chance.. visual 2010
    Bonjour,

    J'ai converti un prog visualc++6 en projet visual 2010,
    un prog en MFC, et j'ai une
    Exception 0xC0000005: Violation lors de la lecture de l'emplacement 0xfeeefeee à la fermeture.
    Clairement, c'est un espace mémoire déja libéré.
    Ce que je cherche à savoir, c'est comment faire pour connaitre la variable mise en cause. Car, l'exception est levée dans atlsimpstr.h, la ou les variables sont normalement releasées, mais il semble qu'elle est déja été releasée.
    Hors, j'arrive pas à savoir de quelle variable CString il s'agit.
    Je cherche donc à savoir de quelle variable on parle..
    Comment faire..??
    J'ai regardé dans la pile des appels, mais je trouve rien de concluant.;
    et vu que j'utilse une tonne de CString..

    Merci de m'aider

  2. #2
    Membre éprouvé
    Avatar de TheGzD
    Homme Profil pro
    Ingénieur/ Docteur en Informatique
    Inscrit en
    Avril 2007
    Messages
    1 327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Ingénieur/ Docteur en Informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 327
    Par défaut
    N'as-tu fais un usage "abusif" du GetBuffer d'un CString local à une méthode/fonction ?

    Si tu utilises des pointeurs mets les à NULL après libération, ça peut parfois éviter bien des désagréments.

  3. #3
    Membre très actif
    Profil pro
    Développeur indépendant
    Inscrit en
    Août 2004
    Messages
    374
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : Août 2004
    Messages : 374
    Par défaut creusons, creusons..
    bon, j'en ai profité pour refaire une verif des GetBuffer et releasebuffer, avec ajout du pointeur à NULL par précaution, bien que ca paraisse futil, vu que normalement la librairie gére la désallocation des variables sur le tas...

    et le resultat n'est pas vraiment mieux, au moins, je sais que ca ne vient pas de ca..
    j'étais habitué à un certains nombre de bugs et d'imperfections sous vC6, mais bon , je les connaissais et on arrivait toujours à peu prés à s'en sortir.
    mais la , c'est vraiment déroutant.
    le bug se situe dans une fonction de atlsimpstr.h, donc sources systeme, ici.
    c:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlsimpstr.h
    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
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    struct CStringData
    {
    	IAtlStringMgr* pStringMgr;  // String manager for this CStringData
    	int nDataLength;  // Length of currently used data in XCHARs (not including terminating null)
    	int nAllocLength;  // Length of allocated data in XCHARs (not including terminating null)
    	long nRefs;     // Reference count: negative == locked
    	// XCHAR data[nAllocLength+1]  // A CStringData is always followed in memory by the actual array of character data
    
    	void* data() throw()
    	{
    		return (this+1);
    	}
    
    	void AddRef() throw()
    	{
    		ATLASSERT(nRefs > 0);
    		_AtlInterlockedIncrement(&nRefs);
    	}
    	bool IsLocked() const throw()
    	{
    		return nRefs < 0;
    	}
    	bool IsShared() const throw()
    	{
    		return( nRefs > 1 );
    	}
    	void Lock() throw()
    	{
    		ATLASSERT( nRefs <= 1 );
    		nRefs--;  // Locked buffers can't be shared, so no interlocked operation necessary
    		if( nRefs == 0 )
    		{
    			nRefs = -1;
    		}
    	}
    	void Release() throw()
    	{
    		ATLASSERT( nRefs != 0 );
    
    		if( _AtlInterlockedDecrement( &nRefs ) <= 0 )
    		{
    			pStringMgr->Free( this );   <==== ERREUR ICI		}
    	}
    	void Unlock() throw()
    	{
    		ATLASSERT( IsLocked() );
    
    		if(IsLocked())
    		{
    			nRefs++;  // Locked buffers can't be shared, so no interlocked operation necessary
    			if( nRefs == 0 )
    			{
    				nRefs = 1;
    			}
    		}
    	}
    };
    comme ca fait juste 3 jours que je suis passé sous vc2010, j'ai trouvé comment charger les symboles détaillés, et finalement, dans la pile d'appels, la fonction qui provoque le probleme est appellée juste aprés la sortie du destructeur de la mainform.

    j'ai cette fonction pour finaliser ma mainform avnt destruction, tuer les threads, etc..
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    void CMainFrame::OnClose() 
    {
        // code divers et variés..
     
       // fermeture de la frame principale MDI
         CMDIFrameWnd::OnClose();
    }
    l'appel à la fonction se fait immédiatement aprés ca..
    en creusant un peu, je m'apercois que le hwnd est déja à 0xfeeefeee,
    normal finalement, puisque je viens d'appeler CMDIFrameWnd::OnClose(); qui justement, detruit la fenetre..
    finalement, en tracant, avec F11, aussitot aprés, je tombe sur
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    // Destructor
    	~CStringT() throw()
    	{
    	}
    dans atlsimpstr.h, sans autre forme de procés..
    c:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlsimpstr.h
    d'autant plus bizarre que j'ai pas demandé le support ATL dans le projet original..
    qui renvoie directement au noeud du probleme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    ~CSimpleStringT() throw()
    	{
    		CStringData* pData = GetData();
    		pData->Release();
    	}
    et la je m'apercois que pData est egal à 0xfeeefeee ..
    bad news, j'ai toujours pas compris d'ou ca vient ..

  4. #4
    Membre éprouvé
    Avatar de TheGzD
    Homme Profil pro
    Ingénieur/ Docteur en Informatique
    Inscrit en
    Avril 2007
    Messages
    1 327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Ingénieur/ Docteur en Informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 327
    Par défaut
    Il faudrait voir ton code pour t'en dire plus.

    A mon avis tu as un problème avec un des attributs de ta classe qui a lui-même instancié un CString.

  5. #5
    Membre très actif
    Profil pro
    Développeur indépendant
    Inscrit en
    Août 2004
    Messages
    374
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : Août 2004
    Messages : 374
    Par défaut bon, ben voila..
    oui, à force de faire le morpion, j'ai enfin trouvé le probléme, c'était moi.. comme d'hab.. on veut trop bien faire, tiens, ce pointeur, je l'ai pas désalloué, ca c'est pas bien.
    allez, hop, un petit delete..
    sauf que c'était sur une classe instanciée sur le tas.
    donc, le gestionnaire a fait son travail, sauf que la reference était déja caduque..
    bon, le coté positif, c'est que j'ai cherché et utilisé des outils un peu plus poussés pour tracer jusqu'au bout..
    windbg par exemple, du debugging tools for windows.
    en cherchant un peu on peut recuperer les fichiers .mdmp ou .hdmp résultants d'un crash programme, dans les journaux windows, et windbg permet d'explorer la pile des appels au moment du crash, trés instructif.
    pour ceux qui ne connaitraient pas ou qui n'en ont pas encore besoin,
    c'est la.

    appeller windbg avec en argument le fichier .mdmp ou .hdmp

    windbg -z fichierdump.mdmp
    dans la fenetre commande en bas, taper cette commande:
    !analyze -v
    ca remet tout en ordre, et la pile d'appel est accessible proprement.
    tout devient limpide.
    pour charger les symboles, voir ici http://support.microsoft.com/kb/311503

    j'ai trouvé à partir de cette discussion.
    http://social.msdn.microsoft.com/For...0-83e3de8d0972

    voila, j'ai encore pris le mur, mais je m'en sors plus fort.

  6. #6
    Rédacteur
    Avatar de farscape
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2003
    Messages
    9 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 9 055
    Par défaut
    salut,
    j'utilise aussi windbg comme ceci:
    dans les options de link débogage : je laisse debug à oui.

    en cas de plantage je récupère : les deux fichiers .mdmp / hdmp.

    j'ouvre le fichier .mdmp.

    puis CTRL+S pour donner le chemin de mon fichier symbols (.pdb) de mon application ce qui correspond au répertoire release de mon programme.
    je clic sur l'option reload de la fenêtre.
    et la miracle on voit la portion de code en clair responsable de l'erreur ...

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Masquer Exception de première chance
    Par Ange44 dans le forum VC++ .NET
    Réponses: 2
    Dernier message: 04/10/2010, 13h09
  2. Exception de première chance
    Par MohEllayali dans le forum C++
    Réponses: 2
    Dernier message: 04/03/2009, 11h29
  3. Message d'Exception de Premiere Chance ?
    Par Danyel dans le forum VB.NET
    Réponses: 1
    Dernier message: 29/05/2008, 14h20
  4. Exception de première chance
    Par Oh-Dae-Su dans le forum C++
    Réponses: 6
    Dernier message: 15/05/2008, 14h17
  5. Exception de première chance
    Par oodini dans le forum C++
    Réponses: 10
    Dernier message: 25/09/2007, 16h09

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