Discussion :

[lapotose]

Bonjour à tous

Ce matin je codais tranquillement quand tout d'un coup je me suis confronté à une sacrée erreur. Le code source n'a pas d'intérêt notable et donc je vous en dispense.

Le problème est le suivant : une fonction malloc(environ 1000 octets) est appelé dans mon programme.
Il y a quelques semaines, pas d'erreur, tout fonctionne nickel.
Ce matin je modifie une autre partie du programme (une autre fonction), et là paf, ça plante. Mais ça ne plante pas immédiatement : la même ligne est exécutée 2 fois sans problèmes et ça plante à la 3eme. Le programme s'arrête brutalement et codeblock me dit "Process return 3".

Encore plus étrange, l'exécution avec le débuggeur fonctionne sans problème et me signale aucune erreur.

Je pensais que c’était dû à un manque de mémoire (bien que cette erreur soit signalé par une valeur de retour à NULL), mais un redémarrage de ma machine n’a rien changé…

Voilà tout pour le moment

Merci d'avance d'éclairer ma lanterne.

[Neckara]

Bonjour,

Ce n'est pas malloc qui retourne 3 mais ton programme.
Quand un programme retourne 3, c'est que tu as une segfault : tu accèdes à un endroit "interdit" de la mémoire.
Ceci peut arriver lorsque tu as des pointeurs non-initialisés, quand tu déférence un pointeur valant nulle ou quand un pointeur pointe sur une zone mémoire qui a déjà été libérée avec free().

Si tu n'as pas de segfault en mode débogage, essaye de mettre des printf pour voir le/les lignes à laquelle se produit l'erreur de segmentation.

[gangsoleil]

Le code source n'a pas d'intérêt notable et donc je vous en dispense.

Et pourtant, ton programme fait exactement ce qui est ecrit dans ton code. Donc s'il y a un soucis, il vient bien de ton code et pas d'ailleurs.

Malloc ne retourne probablement pas 3, car malloc retourne une adresse, et l'adresse 3 est reservee au systeme sur la tres tres tres tres grande majorite des OS grand public (donc en gros sauf si tu executes ton programme sur un micro-controlleur, c'est le cas).

Ce qui est probable, c'est que tu aies un probleme dans la gestion de la memoire, avec un acces a une zone à laquelle tu n'es pas cense acceder.

[lapotose]

Oui en effet malloc ne retourne pas 3 ni quoi que se soit d'autre. Le programme semble s'arrêter au beau milieu de la fonction malloc, comme s’il y avait une segfault interne à malloc

Le 3 vient effectivement de codeblock.

Information supplémentaire : lorsque je lance le programme normalement (hors de codeblock, directement en lançant l'exécutable), Windows me coupe mon programme mais sans le message "Le programme a eu une erreur et doit se fermer...", que j'obtiens principalement lors d'une segfault... Donc il semblerait que se n'en soit pas une.

Et ceci n'explique pas pourquoi l'exécution avec le débuggeur ne donne aucuns problèmes...

[gangsoleil]

Et ceci n'explique pas pourquoi l'exécution avec le débuggeur ne donne aucuns problèmes...

La plupart des debuggers ont un fort impact sur la gestion de la memoire, notamment en initialisant tous les pointeurs a NULL et ce genre de choses.

Ce n'est pas rare que l'execution avec debugger change le comportement des erreurs.

[Bktero]

Et ceci n'explique pas pourquoi l'exécution avec le débuggeur ne donne aucuns problèmes...

Si, cela s'explique souvent par le fait qu'en mode débogue, la mémoire est initialisée (souvent avec des zéros) alors qu'en mode "normal", elle ne l'est pas et contient n'importe quoi. Donc très certainement, tu essayes d'accéder à une adresse, peut-être avec un offset non initiliasé. En débogue, ça marche car les valeurs sont "cohérentes", en normale, ça plante.

Montre nous un code minimaliste qui reproduit le problème.

[matafan]

Si ça ne plante pas dans le debugger, il te faut dans un premier temps exécuter ton programme sans le debugger et récupérer le coredump. Puis tu lances le debugger avec le coredump, et tu regardes où ça a planté... Et essaies de comprendre pourquoi.

Cela dit si ton programme ne fait vraiment "rien de notoire", tu peux certainement trouver l'erreur avec un simple relecture attentive de ton code. Tu dois faire un truc pas net du genre libérer deux fois la même allocation.

[lapotose]

Bon, je vais surement passer pour un imbécile mais j'ai deux choses à dire :
1) Comment créer le coredump ?
2) Je suis dans l'incapacité pour l'instant de vous fournir un bout de code, car je phénomène est très aléatoire : voici 3 exemples :
- Mon erreur se produit dans une fonction de 150 lignes environ et mon erreur se trouve aux environ de la 50ème. Et tenez-vous bien, si j'enlève les 100 lignes qui suivent mon erreur, plus de problème, l'exécution se passe sans problème (ou plutôt elle plante autre part, mais c'est normal puisque je n'ai pas fait certaines opérations)
- Et si je passe du mode Debug au mode Release, le comportement n'est plus le même.
- Enfin il semblerait que la présence de printf pour débugger le code influent sur son fonctionnement, ce qui parait stupide, et pourtant...

Voilà tout pour l'instant, et je suis désolé de ne pouvoir vous fournir actuellement des informations un peu plus complètes mais je ne vois pas comme analyser ce souci pour le moment...

PS : pour ceux qui m'ont parlé de libération multiples ou d'accès à une zone de mémoire non allouée, je ne vois pas vraiment le lien direct avec mon problème qui est une allocation qui plante, donc normalement l'ancienne valeur de mon pointeur de sortie (celui qui est rempli par malloc), ne devrais avoir aucune influence sur l'allocation, de même que les valeurs qui sont à ce moment en mémoire...

[Obsidian]

Bon, je vais surement passer pour un imbécile mais j'ai deux choses à dire :
1) Comment créer le coredump ?

En travaillant sous Unix.

- Enfin il semblerait que la présence de printf pour débugger le code influent sur son fonctionnement, ce qui parait stupide, et pourtant...

Non, ça s'appelle un bug intermittent, lequel peut avoir deux causes :

• Ta machine commence à avoir de l'âge et la mémoire devient défectueuse. Passe un coup de memtest86+ pour t'en assurer, mais c'est peu probable ;
• Ton code est congénitalement mal écrit et ne fonctionne que par coup de bol. Si le moindre détail change dans ton environnement, cela peut le faire basculer dans une situation où il cesse de fonctionner.

En particulier, les problèmes qui apparaissent aléatoirement et qui disparaissent inexplicablement en insérant des printf et/ou en fonctionnant en mode debug sont caractéristiques des races conditions, qui se produisent en environnement multi-thread.

Ça arrive aussi lorsque le système spécifie qu'il peut être indisponible et que l'on en tient pas compte. Dans une boucle en temps normal, le résultat attendu n'est pas encore disponible et on reçoit un pointeur NULL que l'on traite comme s'il était valide. En insérant un printf ou en travaillant en environnement de déboguage, on préempte de fait le processus, ce qui suffit à le ralentir suffisamment et à passer la main au système ou à la ressource chargée de nous renvoyer ce dont on a besoin.

Quelle taille fait ton code en tout ? Si c'est l'affaire de 150 lignes, tu peux le poster ici mais en veillant bien à mettre les balises CODE.

[Bktero]

As-tu essayé d'utiliser un outil tel que Valgrind (memcheck) ou drmemory ? On appelle ces outils des débogueurs mémoires et seront sans doute utiles dans ton cas. Voir : http://www.developpez.net/forums/d12...ows-and-linux/

[matafan]

pour ceux qui m'ont parlé de libération multiples ou d'accès à une zone de mémoire non allouée, je ne vois pas vraiment le lien direct avec mon problème qui est une allocation qui plante, donc normalement l'ancienne valeur de mon pointeur de sortie (celui qui est rempli par malloc), ne devrais avoir aucune influence sur l'allocation, de même que les valeurs qui sont à ce moment en mémoire...

Un segfault pendant un malloc est typique d'une double désallocation. En désallouant une zone deux fois, tu corromps les structures internes de l'allocateur, et à la prochaine allocation, bam.