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

Citation:

---

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

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.

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:

---

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:

---

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:

---

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:

---

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

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.

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. :aie:

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

Citation:

---

Envoyé par farscape

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.

---

ben justement, le plantage se produit sur site, et c'est pas bien clair dans ma tete le processus de generation des fichiers dmp. vu qu'il faut que je puisse l'expliquer aux utilisateurs pour pouvoir le recuperer.
est-ce que ca se genere tout seul et à quelle condition ou est-ce qu'il faut faire une action spéciale lors du crash ou juste aprés pour avoir ces fichiers.??
merci d'avance..

salut ,
Tout le problème est la ! : les fichiers sont conservés tant que le message reste ouvert ,si l'utilisateur ferme le message ou active ne pas envoyer c'est mort les fichiers sont supprimés .
dans mon cas je suis sauvé car l'application tourne en terminal serveur et les erreurs remontent sur la console de l'administrateur ...

une possibilité que je n'ai pas eu le temps d'essayer , c'est de désactiver dr watson pour voir si les fichiers sont conservés :

http://support.microsoft.com/kb/188296

comme je disais dans le titre, c'est le noeud du probleme..
peut on configurer un vista ou un seven ou un xp pour qu'il genere automatiquement les fichiers de dump d'une application qui crash et en conserve les fichiers. ecraser les fichiers, pas top. on peut avoir plusieurs causes qui se déclenchent pas en même temps.
vu la taille des applis, pouvoir débuguer une application s'executant à distance est primordial.
un exemple bete..
j'avais un plantage juste sur la generation d'un message EDI, sur le poste client, à calais, alors que je suis à bordeaux..
et ben un dump m'a beaucoup aidé à comprendre que c'était une sombre histoire de droits d'ecriture sur un repertoire windows. juste parcequ'il avait été créé avec un autre compte.
mais la n'est pas le probleme.
dans ce cas, j'ai pu comprendre avec une session teamviewer, comme si j'étais devant. mais dans le cas d'installation non connectées au net, on fait comment??
quelles consignes à donner ou quel reglage mettre en oeuvre dans le systéme ou lors de la compil pour être sur de generer ces fichiers dump..?
et la, je parle pas que pour moi, d'autres pourraient être interressés.
les infos qu'on trouve sont trop rares, repetent les mêmes docs vides de sens, et ne proposent pas vraiment de solutions concretes, contextuelles et verifiables..
d'ailleurs en passant, ca devrait constituer un chapitre à part entiére de la faq visualc++, c'est vraiment un truc à se taper la tete contre les murs..