Discussion :

[Invité]

Bonjour à tous,

Lorsque j'éxécute mon programme sous visual, que ce soit en Debug ou Release, tout ce passe bien.
J'ai par contre un plantage lorsque j'éxécute le .exe en dehors de l'IDE.

J'ai bien-entendu essayé de chercher l'erreur à cout d'affichage de MessageBox un peu partout. Je pense avoir isolé le probleme au niveau d'un de mes algos mais ça a quand meme l'air d'être assez aléatoire (ie ça plante pas au meme endroit à chaque fois).

Est ce qu'il y a des cas de figures ou ce genre de choses peut se produire ?
Est-il possible de débuguer mon .exe sachant que j'ai le source ?
Je suis un peu perdu là.

Merci par avance.

[JolyLoic]

Ca peut être simplement une histoire de répertoire courant ou de variable d'environnement différents...

Autrement, pour debugger, tu peux lancer ton programme depuis une ligne de commande, puis t'accrocher dessus avec l'environnement de développement (éventuellement après avoir mis une pause si le programme plante trop vite pour que tu aies le temps de t'accrocher).

[Invité]

Merci JoyLoic. Je ne comprend pas le "puis t'accrocher dessus avec l'environnement de développement".

Comment je "greffe" Visual à mon exe ?

[jblecanard]

Salut

Dans le menu "Debug", il y a une entrée "Attach to process". Une liste des *.exe en cours d'exécution apparaît. Tu sélectionnes le tien et tu cliques sur "Attach". Le débuggueur va se greffer sur l'exe.

[Invité]

Ok merci jblecanard.
Bon ça ne m'apprend rien de particulier en fait "Exception non gérée blabla".

J'arrive à faire tourner mon exe quand il est compilé en debug mais il plante tjs quand il a été compilé en release.

Du coup je en pense pas que ça vienne d'un quelconque probleme de chemin/variable d'env.

[jblecanard]

Ok merci jblecanard.
Bon ça ne m'apprend rien de particulier en fait "Exception non gérée blabla".

Dis nous en plus ! De quelle exception s'agit-il ? Par défaut, le débuggueur ne s'arrête pas sur toutes les exceptions, mais on peut le configurer pour qu'il s'arrête sur certaines précisément. Ainsi, tu verras d'où est ce qu'elle provient dans le code.

[Feriaman]

Bonjour,

J'arrive à faire tourner mon exe quand il est compilé en debug mais il plante tjs quand il a été compilé en release.

Tu gères comment ta mémoire ?
Tu alloues de la mémoire à la main (pointeurs, tableaux) ?
Souvent les erreurs d'allocation mémoire induisent des comportement très différents en release et en débug.

La raison en est que si on lit ou on écrit au hasard en mémoire, on a une chance de lire ou d'écrire un case mémoire que ton programme n'a pas reservée.
Or en Debug, ton programme réserve beaucoup plus de mémoire pour tout un tas de choses, donc tu as plus de chance de tomber sur une case mémoire que ton programme a réservé, mais qui ne sert pas une fonction vitale du programme (et donc tu ne vois pas que tu es en train de faire n'importe quoi).

[EDIT]
Je me rend compte que c'est pas clair.
Si tu écris à l'adresse d'un pointeur ou dans un tableau :

• Cas normal : tu as, au préalable, réservé cet espace pour ton pointeur ou ton tableau (ou pas assez), ya pas de problème
• Cas anormal 1 : tu n'as pas réservé d'espace pour ton pointeur ou ton tableau. Donc tu écris n'importe où en mémoire. Mais tu as de la chance, le n'importe où en question se trouve être un emplacement que ton programme a réservé pour autre chose, c'est un problème mais tu ne le vois pas forcément. Surtout si le autre chose en question n'est pas (ou plus) directement utile au déroulement de ton programme.
• Cas anormal 2 : tu n'as pas réservé d'espace pour ton pointeur ou ton tableau. Donc tu écris n'importe où en mémoire. Mais tu n'as pas de chance, le n'importe où en question se trouve être un emplacement que ton programme n'a pas réservé pour autre chose. Ton programme crashe avec un joli Segfault.

Du coup, comme la mémoire réservée par ton programme est très différente en release et en debug, le symptome est parfois très différents.

J'espère que c'est plus clair
[/EDIT]

Cela dit :

Dis nous en plus ! De quelle exception s'agit-il ?

+1

[Invité]

Oui j'alloue pas mal de pointeurs et de tableaux ainsi que des std::vector.
Et tu étais clair, merci

Voilà ce que j'arrive à récupérer dans la fenetre sortie :

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
 
Le thread 'Thread Win32' (0x1048) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0xff8) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x16d4) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x122c) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x1688) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x1194) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x16b4) s'est arrêté avec le code 0 (0x0).
Windows a déclenché un point d'arrêt dans MonProg.exe.
 
Windows a déclenché un point d'arrêt dans MonProg.exe.
 
Cela peut être dû à une défaillance du tas qui indique un bogue dans MonProg.exe ou l'une des DLL chargées.
 
Cela peut également être dû à l'appui sur la touche F12 lorsque Dental.exe a le focus
 
La fenêtre Sortie peut contenir des informations de diagnostic supplémentaires.

Et si je continue l'execution, je tombe sur un jolie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Exception non gérée à 0x7c921d8f dans MonProg.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x00000000.

Donc je dois bien taper n'importe ou dans la mémoire, va falloir que je retrousse les manches...
Fallait que ça tombe sur un énorme algo en plus, il m'a fait un jolie poisson d'avril mon prog là...

Par contre, comment se fait-il que ce problème n'apparaisse pas dans Visual, en Release ? Visual alloue-t-il de lui-même plus de mémoire ?

[jblecanard]

Hello

Tu va facilement trouver l'origine de ton problème : tu tentes de déréférencer un pointeur nul. Pour trouver où, rien de plus simple. Dans visual, tu vas dans "Debug -> Exceptions" et dans "Win32 Exceptions", tu coches "C0000005: Violation d'accès". Ensuite tu débuggues, et ça s'arrêtera pile poil sur la ligne qui provoque cette erreur.

Une fois que tu auras trouvé, prend garde à bien comprendre pourquoi tu as fait l'erreur. Ne te focalises sur l'erreur en elle même : il faut bien que comprennes ce qui t'as poussé à la faire, surtout si tu as beaucoup d'allocations de mémoire comme tu sembles le signaler. Au moins, tu n'es pas dans un cas d'incohérence : un pointeur nul n'a rien d'incohérent (tant qu'on ne le déréférence pas).

[r0d]

Par contre, comment se fait-il que ce problème n'apparaisse pas dans Visual, en Release ? Visual alloue-t-il de lui-même plus de mémoire ?

Le code n'est pas compilé de la même façon en release et en debug. Il y a beaucoup de différences, donc beaucoup d'explications possibles.

Le plus fréquent dans ce type de comportement, c'est une mauvaise initialisation de pointeur (ou de tableau dynamique, ce qui est en fait la même chose). Quand tu déclare un pointeur, si tu ne l'intialise pas toi-même, visual l'initialise avec une valeur différente selon que tu compiles en debuf ou en release. Je ne sais plus exactement, je crois que c'est 0xcdcdcdcd en debug et 0xfefefefe en release, quelque chose comme ça.

Quelques conseils donc:
niveau 1: vérifie toutes les initialisations de pointeur. Ne laisse jamais un pointeur non initialisé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
UnObjet * mon_pointeur; // pas bon
UnObjet * mon_pointeur = NULL; // ok

niveau 2: utiliser des références à la place des pointeurs

niveau 3: utiliser des pointeurs intelligents et pas des pointeurs nus

[Invité]

En fait je en sais pas si tout le monde m'a compris.

Je sais qu'il y a des différences entre Debug et Release, je m'interroge plus sur les différences entre ".exe en release" ou ".exe en release par visual".

Mon probleme principale est que quand je lance mon programme en Release ET via visual, aucun probleme. Par contre, quand je lance mon prog en dehors de l'IDE (ie je double clic sur l'exe), ça plante !

@jblecanard En fait je n'arrive pas à obtenir l'emplacement.
Si je dois deboger quelquechose, il s'agit de mon exe en Release (d'ou le probleme...). Après ce que j'ai essayé de faire c'est ça :
- ouvrir mon projet MonProg sous visual,
- me mettre en mode debug,
- executer MonProg.exe (précédemment compiler en release),
- attacher MonProg.exe à visual + checker les exceptions.

Mais dans ce cas là je n'ai aucune infos de plus que ce que j'ai posté précédemment.

J'ai de plus en plus l'impression qu'il va falloir que je vérifie mes pointeurs 1 par 1

En tout cas merci pour votre aide

[nirgal76]

En mode debug, les variables sont initialisées à 0, et les pointeurs à NULL, ce qui n'est pas toujours vrai en release ou la valeur est indéterminée (j'ai eu parfois des surprises en passant en release (avec Builder C++).

[r0d]

Est-ce que tu utilises des ressources externes dans ton programme? Je pense en particulier à des fichiers. Je dis cela car il y a peut-être un problème de path.

Est-ce qu'il plante au démarrage ou après avoir avoir démarré? Car il ya peut-être un problème de dépendance.

Utilises-tu des dlls de facon dynamique? Peut-être y a-t-il un problème de path.

[screetch]

En mode debug, les variables allouées sur le tas sont uinitialisées a CDCDCDCD et celles allouées sur la piles a CCCCCCCC
en release elles ne sont pas initialisées, on tombe statistiquement plus souvent sur des 0 mais sans garantie.
Un booléen, c'est ca le problème, sera initialisé a CD ou a DD c'est a dire true, en debug, et pas en release, ce qui conduit souvent a des résultats différents.

@azboul
dans les options de projet tu peux activer ou desactiver quelques trucs mais un exe en release se debugge quand même pas si mal.
la tu as deux problèmes d'affilée:
* d'abord tu as un point d'arrêt: il t'indique une première erreur
* puis si tu continues uncrash, mais cela il ne faut pas en tenir compte puisque tu avais deja une erreur avant
la violation d'accès donc, pour l'instant, on s'en fout, revenons sur ton preier problème:

Windows a déclenché un point d'arrêt dans MonProg.exe.

Windows a déclenché un point d'arrêt dans MonProg.exe.

Cela peut être dû à une défaillance du tas qui indique un bogue dans MonProg.exe ou l'une des DLL chargées.

Cela peut également être dû à l'appui sur la touche F12 lorsque Dental.exe a le focus

La fenêtre Sortie peut contenir des informations de diagnostic supplémentaires.

Ces points d'arrêts font parties de la version de debug des DLLs de visual studio, il y a donc quelques points d'arrêt de ci de la lorsque le programme fait quelque chose de mal.
Ce que j'ai vu le plus fréquemment, c'est que le point d'arrêt est declenché lorsqu'il y a une corruption mémoire.
Lorsque ton programme rencontre ce point d'arrêt, il ne faut pas continuer; il faut regarder la "call stack" (pile d'appel) et voir dans quelle partie du programme ca plante.
Pour attrapper plus de problèmes (si ca vient effectivement d'un ecrasement mémoire detecté par windows) on peut aussi ajouter ce code au démarrage:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <crtdbg.h>
...(main ou winmain)
{
  _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_CHECK_ALWAYS_DF);
  ....
}

[Klaim]

Vu que le probleme n'apparait qu'en double clickant sur l'exe, c'est certain : ton programme a besion d'une dépendance qui n'est pas accessible. Rien a voir avec une quelconque build.

Si c'est une dll, elle sera cherchée d'abord dans le répertoire courant, ensuite dans celui du systeme, sinon ça crashera si elle n'est pas trouvé dans ces dossiers. Si l'erreur dit qu'il faudrait réinstaller l'application, cherche pas c'est ça. Vérifie tes dépendances avec dependency walker ou quelque chose comme ça.

Vérifie aussi dans l'application que tu ne manipules pas le dossier de travail (qui par défaut est le dossier dans lequel se trouve l'exe si tu doubles click, le dossier en cours si t'es en ligne de commande).

C'est un problème de contexte.

Tu peux aussi regarder tes réglages dans visual studio, propriétés du rpojet, dans la partie debuggage, il y a des path. Vérifie les, ils sont certainement fait pour debugger l'exe en prenant en compte des dossiers où se trouvent des dépendances.

Si tu as des dll, rassemble les dans le dossier de ton exe. Je fais ça par script perso, qui est executé a chaque post-compilation (voir propriétés de projet). Ca me crée un dossier nomé selon le type de build, puis ça le remplis avec toutes les dépendances. Puis ça met les binaires qui viennent d'être compilés dans le bon dossier.
J'ai réglé le projet pour que le débuggage lance l'executable une fois déplacé et lance le tout dans le dossier ou se trouve l'executable. De cette façon, que je double click ou que je lance une session de debuggage, c'est toujours le même contexte coté fichiers binaires.

De plus je peu ziper mon dossier Release et l'envoyer a quelqu'un parceque j'ai fait en sorte que toutes les dépendances et les resources soient dedant.