Reprise du message précédent :
Oui.

 
 
laquelle ?

il me sort des erreurs pendant l'installation
 
j'y arrive pas ce truc

 
Que te dis le debugger ?

mais je sais pas m'en servir moi

et l'autre truc valgrind l'installation marche pas j'ai une erreur

L'astuce, c'est qu'un debugger est vraiment un outil essentiel. Prends ton temps : ce que tu perds maintenant, tu le gagneras au centuple ensuite.

nouveau coup de théatre
 
j'ai grisé la fonction, j'ai mis une valeur bidon a la place du résultat qu'elle était cernsée fournir et ca plante plus

bon pour ceux que ça intéresse j'ai trouvé le probleme
 
en fait j'avais un autre pointeur dont je n'avais pas alloué de mémoire pour et je m'en servai quand meme
 
étrangement, il ne m'a pas signalé d'erreur pour ce pointeur mais il a foutu le bordel en mémoire et cela s'est répercuté sur un autre  
 
bref

Valgrind te l'aurait signalé, mais c'est très bien d'apprendre à détecter ce genre de bugs soi-même. Mais au fait, j'ai oublié de te dire que ça ne fonctionne que sous Linux...

rebonjour, en fait j'ai quand meme testé mon programme avec valgrind pour vérifier
 
 mais je comprends rien a ce qu'il me sort meme avec la notice
 
un ptit coup de pouce svp ?
 
merci
 
= Memcheck, a memory error detector.
==6653== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6653== Using LibVEX rev 1367, a library for dynamic binary translation.
==6653== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==6653== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==6653== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6653== For more details, rerun with: -v
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1B8F56BF: index (strchr.S:177)
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1B8F56D0: index (strchr.S:183)
 
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x804BFEA: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Use of uninitialised value of size 4
==6653==    at 0x1BB30D99: ??? (_itoa.c:191)
==6653==    by 0x1BB34010: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1BB30DA1: ??? (_itoa.c:191)
==6653==    by 0x1BB34010: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Use of uninitialised value of size 4
==6653==    at 0x1BB30DBC: ??? (_itoa.c:191)
==6653==    by 0x1BB34010: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1BB30DC4: ??? (_itoa.c:191)
==6653==    by 0x1BB34010: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1BB3450C: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== Conditional jump or move depends on uninitialised value(s)
==6653==    at 0x1BB32BA2: vfprintf (vfprintf.c:1534)
==6653==    by 0x1BB3B021: fprintf (fprintf.c:32)
==6653==    by 0x804C10F: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
fin boucle 0
==6653==
==6653== Invalid free() / delete / delete[]
==6653==    at 0x1B9003B3: free (vg_replace_malloc.c:235)
==6653==    by 0x804C1ED: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==  Address 0x1BC2C5B0 is 0 bytes inside a block of size 104000 free'd
==6653==    at 0x1B9003B3: free (vg_replace_malloc.c:235)
==6653==    by 0x804C1CE: main (in /home/hbusson/Desktop/Simulations/simu1/badbadthing)
==6653==
==6653== ERROR SUMMARY: 687237 errors from 10 contexts (suppressed: 23 from 2)
==6653== malloc/free: in use at exit: 1706960 bytes in 19391 blocks.
==6653== malloc/free: 37508 allocs, 18118 frees, 3426804 bytes allocated.
==6653== For counts of detected errors, rerun with: -v
==6653== searching for pointers to 19391 not-freed blocks.
==6653== checked 1665792 bytes.
==6653==
==6653== LEAK SUMMARY:
==6653==    definitely lost: 192720 bytes in 2190 blocks.
==6653==      possibly lost: 264 bytes in 3 blocks.
==6653==    still reachable: 1513976 bytes in 17198 blocks.
==6653==         suppressed: 0 bytes in 0 blocks.
==6653== Use --leak-check=full to see details of leaked memory.

ya personne

Je connais pas valgrind mais à priori tu utilises des pointeurs non initialisés, de même que tu ne libères pas toute la mémoire que tu alloues.

merci
 
mais je fais quoi alors ?
 
parce qu'il me dit pas ou sont les erreurs

Met un point d'arrêt au début de ton programme,
tu le déroules pas-à-pas , et tu vérifies la sortie de valgind pour chaque ligne.
 
Ainsi tu connaitra les variables en jeu aux moments où ça foire, et tu pourras vérifier leurs initialisation.
 
Oui, c'est pénible.
 
Le mieux est encore de vérifier toi même qu'à chaque fois que tu utilises une variable, tu t'assures qu'elle soit initialisée, et que tu la libère à la fin de son utilisation, ca DOIT être un reflexe.

 
la fonction en question doit surrement faire un depassement de memoire qui ecrase le pointeur su cité.
 

 
Tu cherches les soucis avec ca. Code proprement et le bug s'en iront d'eux meme (les bugs n'aiment pas les codes trop propres, ils preferent les bon gros codes biens crassoux, ou ils peuvent se nivher bien au chaud sans etre debusqués.
 
Pour revenir au probleme, faut que tu cherche ou est ton pointeur en memoire (&e4), et regarder qu'est ce qui, dans ta fonction, trafique du coté de ces adresse, tout particvulierement a des zones non alouées.
 
Au passage, ca n'est pas lié a ton bug, mais tu ne fais aucun free. Ton programme est bon pour faire crasher la machine a long terme en lui bouffant toute sa memoire et tout son swap . . .
 
PS: oui, ca ne repond en rien a la question, mais si on te donne la reponse a chque fois, tu ne progressera pas, je trouves ca plus interessant pour toi te t'aider indirectement sans donner la solution.

Ou alors tu compile avec -g3 et valgrind sortira les numéros de ligne ou y'a un problème.

 
 
c'est quoi -g3 ?
 
ou ça ?

 
 
 
=> man gcc
 
 

dites j'ai réussi a corriger les erreurs sauf les deux premieres là
 
 
=                   Conditional jump or move depends on uninitialised value(s)
==32569==    at 0x1B8F56BF: index (strchr.S:177)
==32569==
==32569== Conditional jump or move depends on uninitialised value(s)
==32569==    at 0x1B8F56D0: index (strchr.S:183)
 
je pige pas il n'est fait aucune mention de mon fichier .c dedan
 
et cela se passe au tout début de l'execution
 
moi yen a pas comprendre

snif personne

gcc truc habituels -g3 c'est aps compliqué !

je l'ai fait !!
 
et il me sort que ce que j'ai mis!
 

Ces deux erreurs semble faire partie d'un blibliotheque, etrange. Ton programme marches ?

oui il marche  
 
ceci dit j'ai mis  gnu scientific librarty (qui est p-e buggée ? )

Bon, j'arrive un peu en retard mais après avoir tout lu, mon avis est qu'un truc pareil il faut le jeter et tout recommencer. T'as vu ta fonction "double determ_tps_sortie" ? Elle prend en entrée 10 paramètres dont un tableau en 2D, 2 pointeurs (es-tu certain de la zone pointée ?) et un tableau de structures. Et comme l'a dit fort justement deadalnix, plus un code est obscur plus il ouvre la porte aux bugs ce qui m'étonne pas quand on voit tes "(*((*e).next)).t" de ton premier code (remplaçable comme l'a dit Elmoricq par "e->next->t" ). Et avec tes noms de variables super intelligents (e, e1, t, t1, pt) et vas-y que je te fais du "e=e1" et "e1=t" et "t=e2". J'ai l'impression que tu sais plus trop où tu vas... sans compter les magnifiques malloc jamais libérés. Et si ça se trouve, ta fonction est appelée 500.000 fois...
 
Tu veux faire des listes chainées ? Ok. Alors commence par poser ta structure pour tenir ta liste. C'est simplement une structure qui contient un pointeur sur le premier élément de ta liste. Ensuite, une fois que la structure est bien posée, elle peut facilement évoluer (tu peux lui rajouter un pointeur sur le dernier élément, un compteur d'éléments, enfin tout ce qui te passe par la tête pour t'aider à gérer ta liste...).
 
Ensuite, tu définis une structure pour gérer les noeuds de ta liste. C'est juste une structure qui contient soit l'élément à stocker (si ce sont de simples variables), soit un pointeur sur cet élément si celui-ci est complexe. Evidemment il faut aussi un pointeur sur le noeud suivant. Plus tard, tu pourras facilement rajouter un pointeur sur le noeud précédent et t'auras ainsi une liste chaînée avant/arrière
 
Ensuite, tu écrits tes fonctions de manipulations. Il y aura en vrac
- une fonction qui te stocke ton élément dans un nouveau noeud et qui te renvoie le noeud créé
- une fonction qui insère un noeud au bon endroit dans la liste
- une fonction qui recherche un noeud particulier dans la liste
Bref, construits-toi de bons outils simples mais fiables, puis utilise-les. Ces fonctions recevront soit un pointeur sur un noeud ce qui leur permettra de manipuler le noeud en question, soit un pointeur sur la liste ce qui leur permettra de manipuler la liste dans son intégralité. Et n'oublie pas que si, dans un de ces outils, tu fais UN SEUL malloc, alors soit:
- tu libères dans ton outil la zone allouée
- tu renvoies la zone allouée à l'appelant pour qu'il puisse lui-même la libérer plus tard
- éventuellement ton outil aura reçu un pointeur dans lequel il viendra stocker la zone allouée (donc un pointeur de pointeur) mais c'est plus crade et on peut s'en passer dans 99,99% des cas
Une fois que t'auras ces outils, toutes tes opérations en seront grandement simplifiées. De toute façon, c'est pareil que pour tout le reste. Quand on doit faire quelque chose, on commence par poser des fondations bien solides pour pouvoir construire dessus...
 
Tu devrais aussi aller voir le lien suivant: http://mapage.noos.fr/emdel/listes_chainees.htm
 
Sinon, pour répondre simplement à ta question initiale, je n'ai aucune idée d'où peut être l'erreur et je n'ai pas envie de me plonger à la recherche du bug perdu dans cette jungle...
 
Ah oui, dernier détail: contrairement aux idées largement colportées par les programmeurs débutants, les commentaires sont utiles... voire nécessaires !!!

 
Voir indispensable, meme si tu es seul a coder sur ce programme ! (bien sur, dasn ce cas, tu peut etre plus light mais il faut en faire quand meme)
 
Sinon tres joli post, plein de bons conseils

bin en ce qui me concerne je me repère très bien dans ce code
 
apres mon programme tourne
 
mais je voulais faire valgrind pour vérifier  
 
je dois etre sur de mes résultats et j'obtiens ces deux dernieres erreurs qui m'agacent
 

Oui mais helas t'es le seul.  
Et crois-moi, t'as toujours interet a ce que ton code puisse etre relu par quelqu'un d'autre ... ou par toi, quelques mois plus tard.

Ou par exemple si tu as besoin de poster dans un forum car il y a un truc qui marche pas .

quelle perspicacite...

Toi très certainement (encore que dans 6 mois... ). Nous, absolument pas !!!
 
 
En C, ce n'est ABSOLUMENT pas une garantie de réussite.  

Bien que je stocke une valeur dans un pointeur indéterminé, il est quasiment certain que ce programme "tournera" sans problème apparent... jusqu'au jour où on y rajoutera une variable qui sera justement implantée en mémoire à l'adresse où pointe "pt" et là... PAF le chien !!!
 
 
bin elles sont très probablement enfouies dans ce code... mais comme tu t'y repères...

 
 
bin oui et non
 
car elles arrivent tout au début du programme
 
si je mets un printf juste apres l'initialisation des variables, l'erreur survient avant le printf donc c'est ça qui est étrange

ok => opération RAZ => tu crées une copie de test de ton programme et cette copie de test tu lui enlèves TOUT sauf les variables en question et ton printf(). Tu compiles et tu run...

pas con
 
merci

Le fait que ton printf s'affiche aps est en aucun cas un preuve du fait qu'il n'est pas atteint. Printf est un sortie TAMPONNEE, donc ta sortie est mis en tampon, et si ton programme se fait tuer ensuite, rien n'en sort.
 
L'erreur peut etre bien etre apres le printf, bonne chance  

 
 
non  non mon ,printf s'affiche bel et bien
 
les erreurs ne font pas planter mon programme
 
je ne sais meme pas quelles sont les conséquences de ces erreurs
 
mais ca me dérange qu'elles soient affichées par valgrind