Différence entre une application lancée depuis VC++ et le binaire compilée

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

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

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

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.

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)

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 ?!

Bonjour,

J'ai trouvé l'origine de l'erreur (malheureusement classique :( )
J'ai un pointeur p non initialisé sur NULL qui peut de temps en temps subir la ligne suivante :

if( p )
delete p ;

Apparemment selon l'organisation des fichiers et le point de lancement de l'application, la zone mémoire détruite n'était pas la même ce qui justifie les crash systématiques mais à des portions différentes du code !

Merci d'avoir essayé de m'aider, c'est le fait de déplacer l'exécutable jusque dans le bon répertoire (pour que le crash ait lieu près de l'erreur) qui m'a permis de résoudre le problème.