Discussion :

[Bazzz]

Bonjour,

Voici mon probl�me :
J'ai une application qui fonctionne parfaitement dans les diff�rentes versions ( RELEASE et DEBUG ) lorsque je l'ex�cute depuis Visual C++ (typiquement F5)

Par contre, le r�sultat de la compilation ne fonctionne pas (sur le m�me poste !)...

Apr�s analyse des crash et une �tude de debuggage, il semblerait que certaines de mes donn�es m�moire soient corrompues. Toutefois, les perturbations semblent "al�atoires". Je mets des "" puisque les erreurs sont syst�matiques dans le sens ou elles sont identiques pour une configuration donn�e et j'utilise le terme al�atoire car elle provoque des erreurs de nature compl�tement diff�rentes (ce ne sont pas les m�mes objets qui sont corrompus) pour des variations minimes et non significatives d'un fichier de param�tres qui n'est m�me pas forc�ment utilis� dans les portions contenant l'erreur !!!

Une id�e ??
Existe-t-il des protections des acc�s m�moires lorsque l'appli tourne depuis VC++ ?

Si cela est important, ma version est 7.1.3088 et le .NET Framework 1.1.4322

Merci

[M�dinoc]

Il y a trois niveau de "dans visual" pour moi:

• Dans le debugger, F5 dans Visual.
• Hors du debugger, Ctrl-F5 dans Visual.
• Hors de Visual.

Est-ce que �a marche avec Ctrl-F5 ? La principale diff�rence entre Ctrl-F5 et Hors-Visual, c'est le r�pertoire de travail...

[Bazzz]

Je ne connaissais pas l'option ctrl + F5 mais venant de la tester dans la seconde, je peux signifier que cela marche...

Avec un peu d'acharnement, j'ai pu d�tourner l'erreur pour qu'elle apparaisse sur une zone de code m'appartenant, et non pas sur un appel faisant intervenir une dll annexe et voila que mes bases vont �tre remise en question !

J'explique :
voici la ligne :

Verin * v = new Verin( tampon ) ;

J'ai une classe qui s'appelle verin (un peu de m�canique mais son contenu n'intervient pas)
tampon est une cha�ne de caract�res ( d�clar�e par char tampon[250] et remplie par un fgets( tampon, 250, adresseL ) ; ou adresseL est une adresse de lecture d'un fichier de param�tre et j'ai un constructeur Verin::Verin( const char * )

Qu'est-ce que je vois comme probl�me :
1) call stack --->


Application_Pelle.exe!Verin::Verin(const char * tampon=0x0608b218) Line 74 + 0x13 C++

Application_Pelle.exe!operator new(unsigned int size=1) Line 12 + 0x6 C++

Application_Pelle.exe!Outil::configurerOutil(unsigned short numMode=30110, const char * nomFichier=0x0645759e, const char * nomRacine=0x016ab338) Line 178 + 0x2e C++

2) Dans mon environnement :
a) constructeur : tampon 0x0608b218 (contenu mauvais)
b) au moment de l'appel (dans configurerOutil) : tampon 0x0012ef04 (contenu correct)

Il y a donc perte de la valeur de la valeur du pointeur tampon en passant par le new ?!!

Pour avoir tester, Verin v = Verin( tampon ) ;
cela fonctionne avec les bonnes valeurs.....

[M�dinoc]

Adresse d'un fichier ?
Ne cherche plus!

Tu viens de tomber sur la diff�rence pr�cise entre Ctrl-F5 et hors-visual.
Avec Ctrl-F5, le r�pertoire de travail est celui du projet.
Hors de Visual, le r�pertoire de travail peut �tre:

• Tout ce que tu veux si tu l'utilises en ligne de commande,
• Celui de l'ex�cutable (typiquement le dossier Debug ou Release) quand tu cliques dessus.

[Bazzz]

Nope, ce serait trop facile... Mes adresses de fichiers sont toutes syst�matiquement cod�es en absolu ( pour la modularit� et une adaptation selon un jeu de mod�les et des d�tails sp�cifiques. )

Ce que je veux dire, c'est que lorsque j'observe la call stack (suite � un crash), ma variable tampon contient bel et bien les bonnes valeurs au niveau de l'appel du new mais � l'int�rieur du constructeur elles sont fausses !

Pour valider cela, je viens de lancer l'application avec F5 et voici la call stack correspondante :

Application_Pelle.exe!Verin::Verin(const char * tampon=0x0012edd8) Line 76 C++

Application_Pelle.exe!Outil::configurerOutil(unsigned short numMode=0, const char * nomFichier=0x0012f76c, const char * nomRacine=0x0012fa6c) Line 174 + 0x2f C++



tampon au niveau de l'appel :
tampon 0x0012edd8



On voit que les adresses repr�sentant tampon sont bien deux fois identiques contrairement � pr�c�demment... ( Je note �galement l'absence du new dans la call stack.)
Pourrait-il y avoir une optimisation de compilation qui poserait probl�me ? Elles sont pourtant � priori toutes bien d�sactiv�es....

Autre id�e ?

PS : J'ai �dit� le message pr�c�dent pour bien mettre en valeur l'erreur des adresses m�moire (si j'ai le droit)

[Bazzz]

J'ai post� tr�s rapidement un message tout � l'heure dont je ne peux assurer la v�racit�. J'ai compris diff�remment le sens du post et ai essay� de d�placer l'ex�cutable dans le r�pertoire du projet.

Toutefois, je ne sius pas certain que les r�sultats aient �t� bien meilleurs... Je confirmerai les tests d�s demain. Je pense tout de m�me que quelque chose se cache derri�re le probl�me de la call stack ?!