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

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

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

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 …

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?

Picodev; tu entends quoi par il tombe en marche?

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

(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

Citation:

---

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

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

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?

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*)

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

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.

Comme ceci metalman?

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

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?

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)

juste pour information, je compile comme ceci :

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

C'est bien ce que tu demande?

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

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

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

Je n'ai pu accès a mon environnement de développement :oops:.

je rouvre les hostilités des demain.

Merci a tous pour votre aide avec dédicace spécial à Métalman.

Le retour de Metalman !

Moi je vois ça :
http://www.developpez.net/forums/att...-memory-3.png/
et je me dis que ce n'est pas la peine d'aller chercher plus loin.

Pour info : http://www.developpez.net/forums/d12...ows-and-linux/