Code blocks : programme fonction en mode debug et non en release (0 warning) et tourne sur d'autres postes

**nysay27** · 26/08/2015, 09h02

Bonjour a tous,

J'ai un programme qui s’exécute correctement en mode debug et non en release. Petit tour sur les warnings qui sont au nombre de 0.Alors, je me demande si le debug fournit des valeurs au départ en terme de mémoire ou d'initialisation de variable qui lui permette d'aller jusqu'au bout mais je ne trouve rien et magie, mon collègue l'embarque sur son PC et il fonctionne parfaitement bien

. Petite précision, j'ai réinstallé code block mais sans plus de réussite.

Je pense que mon collègue n'a pas changer la configuration initale de code blocks.

C'est un problème machine?

Merci

**ternel** · 26/08/2015, 10h10

As-tu bien activé tous les warnings avec l'équivalent de -Wall -Wextra de gcc ou /W4 de visual studio?

Quand ca ne fonctionne pas en release, mais en débug, en général, c'est parce que le mode débug initialise scrupuleusement toutes les variables à 0 par défaut.
C'est notamment le cas des pointeurs.

Pour résoudre le problème, il n'y a que trois choses à faire:

Utiliser un débuggeur pour savoir ce qui pose problème.
Réduire les portées des variables
Initialiser les variables aussi tôt qu'elles sont déclarées. C'est à dire déclarer les variables uniquement quand on sait les initialiser.

Ce en quoi, si tu nous disais ce que signifie concrètement ton "ca marche pas", ca serait plus simple d'aider.
En l'occurence, c'est un crash? des valeurs erronnées, pas de valeurs, un message d'erreur?

Si ca marche chez ton collègue, c'est a priori qu'il n'a pas exactement la même configuration: une version différente de la bibliothèque standard, du compilateur, des bibliothèques systèmes, de processeur, d'OS, ou que sais-je encore

**picodev** · 26/08/2015, 11h39

Bonjour,
ça sent le heisenbug … il «tombe en marche» chez ton collègue et ne fonctionne pas chez toi. À vue de nez je te dirais bien que c'est un accès illégal à une mémoire que tu n'as pas alloué. Chez ton collègue la valeur aléatoire accédée ne fait pas planter, chez toi ça plante.
En plus des bons conseils de Leternel, tu peux essayer de passer ton programme par Valgrind ou équivalent, utiliser les address sanitizer si tu compiles avec gcc ou clang …

**nysay27** · 26/08/2015, 11h41

oui c'est un crash. Pur et simple.

Utiliser un debogger est impossible puisque lui fait tout ce que je demande dans mon programme. toutes les variables sont initialisées.

Est ce que l'allocation mémoire sur un ordinateur peut être différents selon son modèle et par extension un programme sans crash sur un peut devenir un problème sur un autre?

**nysay27** · 26/08/2015, 12h12

Picodev; tu entends quoi par il tombe en marche?

**nysay27** · 26/08/2015, 12h57

Pourriez vous me donner une solution pour visualiser ce problème de mémoire avec code block sous windows. J'ai fait des recherches mais ce n'est pas très varié pour le débogage mémoire.

Merci

**Metalman** · 26/08/2015, 13h42

(désolé de te suivre hihi)

Utilise Dr Memory sur windows !

Les paramètres à lui donner :
drmemory.exe -show_reachable c:/dossier/mon_executable.exe param1 param2

**picodev** · 26/08/2015, 14h41

Envoyé par nysay27

Picodev; tu entends quoi par il tombe en marche?

C'est un coup de chance s'il fonctionne … un peu le contraire de tomber en panne ^^

**nysay27** · 26/08/2015, 14h51

Mais merci metalman de me suivre.Tu m'a beaucoup aidé

.

Je vous fait partager mes exploration docteur memory et je veux juste votre point de vue.

Pour les premières erreurs, c'est un problème d'initialisation de variable.Mais même si j'initialise toute mes valeurs, j'ai quand même un scratch donc next errors.

Error 4 et 5 : il me dit en gros que les deux malloc ont scratchés.Mais ce que je comprend pas, c'est que il ne me dit pas que j'ai eu une débordement de mémoire (0 bytes beyond last valid byte in prior malloc).Les données traitées par mon fichier étant assez importantes, est ce que il n'y aurait pas une fuite de mémoire, vu que je libère mes tableaux et structures qu'a la fin du programme?

**Metalman** · 26/08/2015, 14h58

Alors ce que j'ai oublié de préciser :

Compile avec les flags de debug !
-g -ggdb !

Même si le programme te semblera fonctionner, il détectera les erreurs ET EN PLUS il t'indiquera la ligne qui fail (<= "il" = Dr Memory*)

**ternel** · 26/08/2015, 14h59

Bingo, des "uninitialized read".
C'est exactement ce que je suggérais

Il ne reste qu'à être rigoureux.
Les endroits probables sont:

les variables globales
les variables déclarées en début de fonction.
les pointeurs

Pour les globales et les déclarations trop tôt, ca va être la plaie à suivre, et c'est la raison même pour laquelle on les déconseille.
Les pointeurs aussi vont être délicats, mais on a rarement le choix.

**nysay27** · 26/08/2015, 15h20

Comme ceci metalman?

La j'avoue que j'ai du mal a me repérer dans la log.

**nysay27** · 26/08/2015, 15h25

Oui l'eternel, il y a des uninitialized read. Nous sommes d'accord que c'est un problème d'initialisation en début de programme des variables qui génère un problème aléatoire au traitement.Mais dans le programme, des valeurs sont attribuées à celle-ci. Il faudrait que ce comportement intervienne avant leurs utilisations?

**Metalman** · 26/08/2015, 15h31

Bizarre... dans mon souvenir c'était différent.
Tu as bien checké que le binaire sur lequel drmemory travaille c'est bien celui en debug avec -g -ggdb ?
La 3e/4e ligne dit : "WARNING : application is missing line number information"...
Donc l'exécutable sur lequel tu fais tourner ça n'est pas le bon...
Fais un clean du projet puis recompile tout (et efface tes .exe avant)

Mais leternel a raison...
Il doit aussi manquer des malloc quelque part... (tu as bien compris le fonctionnement des chaînes de caractères avec le '\0 final' vs 'taille exacte de la chaîne' / strlen vs strnlen ?)
Faudrait que tu balances ton code + la log texte de drmemory (une fois que tu as compilé avec les bons flags)

**nysay27** · 26/08/2015, 15h38

juste pour information, je compile comme ceci :

mingw32-gcc.exe -Wall -O2 -Wextra -Wall -g -c

C'est bien ce que tu demande?

**Metalman** · 26/08/2015, 15h44

Outch outch outch...

Alors quand tu travailles, il faut au moins :
mingw32-gcc.exe -Wall -Wextra -std=c99 -pedantic

Et quand tu debugges, tu peux ajouter :
mingw32-gcc.exe -Wall -Wextra -std=c99 -pedantic -g -ggdb

Et là tu auras toutes les infos nécessaires pour qu'un debuggeur te montres "où" se situe les problèmes

**nysay27** · 26/08/2015, 16h13

Je pense avoir tout bien fait mes toujours 0 warning et pas d'informations en plus sur dr memory.

**Metalman** · 26/08/2015, 16h25

Ok... alors d'après la doc DrMemory, il faut générer les infos de debug au format "dwarf2"... (bizarre, la doc gcc dit que -ggdb embarque déjà DWARF2...)
J'ai peut être oublié le -g3

Essaye donc tous ces flags :

-Wall -Wextra -std=c99 -pedantic -g -g3 -ggdb -gdwarf-2
(et retire le -gdarf-2 si il râle)

EDIT :
Si ça ne marche pas, la doc drmemory donne ça :
-static-libgcc -ggdb -o myapp.exe myfile1.cpp myfile2.cpp

Et balance la version de ton mingw stp...
mingwgcc --version ou -v...