valgrind erreur tableau de structure dynamique

là je ne comprends pas ce que tu veux dire.
Je t'ai expliqué que i ne peut pas prendre des valeurs supérieur à size_tri où égale à size_tri. Pour le démontrer j'ai écrit la ligne de code de mon dernier topic et bien constaté que le problème ne vient pas de là. Si ça arrivait le programme sortirait de la boucle, ce que je veux.

Mais avant de sortir de la boucle que se passe-t-il? (juste dans la ligne de ton for)

Si i est égal à size-tri? Remplace i par size_tri si tu narrive pas à le voir.

ok là je vois, il faut inverser ces deux instructions.

En fait ça dépend du compilateur.

Théoriquement, avec l'opérateur '&&', dès la première condition fausse, il s'arrête et ne regarde pas la seconde condition.

Mais avec certains compilateur, il regarderait quoi qu'il advienne les deux conditions.

Tu peux tester très simplement :

Code:

---

1 2 3

if(false && printf("O") );

---

ok! je pensais que mon compilateur regardais les deux assertions.
Mais en fait il s'arrête à la première assertion fausse.
Par contre le problème de fuite de mémoire et un mystère pour moi.
Je vois où le compilateur signal le problème mais je ne comprends pas l'erreur.

Tu peux montrer l'erreur qu'affiche le compilateur?

ok!
voici le message que me donne valgrind :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

==6645== Memcheck, a memory error detector ==6645== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==6645== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==6645== Command: ./main ==6645== ==6645== ==6645== HEAP SUMMARY: ==6645== in use at exit: 39,059,316 bytes in 4,880,413 blocks ==6645== total heap usage: 24,553,018 allocs, 19,672,605 frees, 2,182,168,884 bytes allocated ==6645== ==6645== 836,088 bytes in 104,511 blocks are definitely lost in loss record 2 of 4 ==6645== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6645== by 0x4013D8: imersion (imersion.c:136) ==6645== by 0x4029FB: main (main.c:40) ==6645== ==6645== 15,293,328 bytes in 1,911,666 blocks are definitely lost in loss record 3 of 4 ==6645== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6645== by 0x400EDE: imersion (imersion.c:85) ==6645== by 0x4029FB: main (main.c:40) ==6645== ==6645== 22,913,880 bytes in 2,864,235 blocks are definitely lost in loss record 4 of 4 ==6645== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6645== by 0x4015A7: imersion (imersion.c:165) ==6645== by 0x4029FB: main (main.c:40) ==6645== ==6645== LEAK SUMMARY: ==6645== definitely lost: 39,043,296 bytes in 4,880,412 blocks ==6645== indirectly lost: 0 bytes in 0 blocks ==6645== possibly lost: 0 bytes in 0 blocks ==6645== still reachable: 16,020 bytes in 1 blocks ==6645== suppressed: 0 bytes in 0 blocks ==6645== Reachable blocks (those to which a pointer was found) are not shown. ==6645== To see them, rerun with: --leak-check=full --show-reachable=yes ==6645== ==6645== For counts of detected and suppressed errors, rerun with: -v ==6645== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2) Expiration de la minuterie durant l'établissement du profile

---

voici immersion.c :

Est-ce que tu peux remettre le fichier immersion.c ici?

(Tu as peut être fait des modifications qui ont décalé les numéros de lignes)


EDIT : merci pour le fichier :
ligne 136 :

Code:

---

1 2 3 4

p_temp=Malloc(2,int); p_temp[0]=q[j][0]; p_temp[1]=q[j][1]; fifo_add(&file,&fin_file,p_temp) ;

---

Quel intérêt ?

Code:

---

1 2	fifo_add(&file,&fin_file, q[j]);

---

ligne 85 :

Code:

---

1 2 3 4 5

p_temp=Malloc(2,int); p_temp[0]=p[0]; p_temp[1]=p[1]; fifo_add(&file,&fin_file,p_temp);

---

idem

Code:

---

1 2	fifo_add(&file,&fin_file,p);

---

ligne 165:

Code:

---

1 2 3 4 5

p_temp=Malloc(2,int); p_temp[0]=r[j][0]; p_temp[1]=r[j][1]; fifo_add(&file,&fin_file,p_temp);

---

encore pareil, je ne te met pas la solution, je pense que tu la trouvera toi-même.

Ta fonction n'est pas du tout ce que je te conseillerais de faire.
Il faudrait faire ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

typedef struct maillon_fifo { struct maillon_fifo * suivant; Valeur valeur;//contenu } Maillon;   typedef struct liste_fifo { Maillon * ptrQueue; Maillon * ptrTete; //éventuellement le nombre de maillon }Fifo;   void fifo_add(Fifo * fifo, Valeur * v) { Maillon * newM = (Maillon *)malloc(sizeof(Maillon); newM->valeur = *v; fifo->ptrQueue->suivant = newM; fifo->ptrQueue = newM; }

---

Code:

---

1 2 3 4 5

p_temp=Malloc(2,int); p_temp[0]=r[j][0]; p_temp[1]=r[j][1]; fifo_add(&file,&fin_file,p_temp);

---

J'ai écrit ces lignes car p est un tableau qui a une adresse allouer.
Si je fais fifo_add(&file,&fin_file,p);
J'aurai un souci car dans ce cas chaque objet dans ma file aura l'adresse de p.
Comme je ne le veux pas je crée à chaque fois un autre tableau (p_temp) qui est similaire à p qui sera stocké dans ma file.

Je pense que je peux modifier ma fonction qui ajoute un éléments dans ma file pour qu'elle fasse cela directement.

Je viens de regarder ta fonction fifo_add, tu as fait une GROSSE erreur.


EDIT :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

void fifo_add( Fifo **p_fifo,Fifo **fin,int *val) { Fifo *new_fifo; /* on créer un nouvel élément de la file */ new_fifo=Malloc(1,Fifo); assert(new_fifo != NULL); /* on fait pointer l'élément vers null */ new_fifo->suivant=NULL; /* on assigne aà l'élément la donné que l'on veut ajouter*/ new_fifo->donnee=val; /* si la file est vide, alors on fait pointer la file vers l'élément que l'on vient de créer */ if(fifo_isempty(*p_fifo)) { *p_fifo=new_fifo; } else { (*fin)->suivant=new_fifo;} *fin=new_fifo; return; }

---

On ne fait JAMAIS ça.
C'est la SEGFAULT assuré. Tu passe en paramètre un pointeur sur un int.
Et tu fait pointer donnee vers cet int.
Mais quel est la durée de vie de cet int ?
Si jamais cet int est détruit et que tu tentes d'utiliser ta file fifo, tu vas provoquer une SEGFAULT.

Deux cas :
- tu veux stocker un nombre connu de int :

Code:

---

1 2 3 4 5 6 7 8 9 10

typedef struct Fifo { int donnee[..]; } Fifo;   for(int i=0; i < taille; i++) { new_fifo->donnee[i] = val[i]; }

---

- tu veux stocker un nombre variable de int :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

typedef struct Fifo { int * donnee; } Fifo;   donnee = (int *)malloc(taille*sizeof(int) ); for(int i=0; i < taille; i++) { new_fifo->donnee[i] = val[i]; }

---

ok je vous remercie, je vais modifier ma file fifo.

j'ai fais rapidement la modification sur mon implémentation de la file fifo, ça marche aucune fuite de mémoire. Je vais la recoder car je préfère votre implémentation.
Par contre je ne suis pas sur des résultats que j'obtiens avec mon algo.
Car j'ai lu l'article et je constate que sur certaines implémentations de la watershed normalement sur cet exemple :

Code:

---

1 2 3 4 5

7 6 5 4 8 5 4 3 9 4 3 2 0 3 2 1

---

le résultat est :

Code:

---

1 2 3 4 5

2 2 2 2 2 2 2 2 0 2 2 2 1 0 2 2

---

mais moi j'obtiens ça :

Code:

---

1 2 3 4 5

2 2 2 2 2 2 2 2 2 2 2 2 1 0 2 2

---

je ne sais pas si c'est moi qui est mal codé ou si c'est l'algo.
dans l'article ils disent :

Citation:

---

A pixel which is adjacent to two different basins, and therefore initially gets labelled
wshed, is allowed to be overwritten at the current grey level by the label of another
neighbouring pixel, if that pixel is part of a basin (lines 40-41). The motivation given
in [52] is that otherwise ‘deviated’ watershed lines may result. This statement is probably
based on an intuitive expectation for the case of functions in continuous space. From our
point of view, an assessment of the correctness of the implementation should be based
solely on agreement with the definition.

---

J'oubliais :

Si tu veux enregistrer le contenu de p[k] et non celui de p[0] dans ta file, tu sais que tu peux faire :

Code:

---

1 2 3 4 5

int k = ...; fifo_add(p_fifo, fin, p + k); //au lieu de fifo_add(p_fifo, fin, p);

---

L'arithmétique des pointeurs est assez amusante :
pointeur p + entier k = pointeur sur le k ième élément à partir de p
pointeur fin - pointeur p = nombre d'élément entre les deux pointeurs

yep, je connais un peu arithmétique sur les pointeurs.
C'est clair que c'est amusant et dans des cas ça sauve.

Le temps d'éditer que tu as déjà répondu :P

Je place mon édit ici :


Tu as des données erronées.
Il y a pas 36 000 solutions.

Méthode 1 : quand tu as bien divisé en plusieurs fonctions, tu fais une fonction test par fonction et tu t'en sert pour tester chaque fonction en leur passant des paramètre que tu définie toi-même et en regardant si le résultat retournée est celui attendu.

Méthode 2 : Tu commences au début de ta grosse fonction, et tu teste régulièrement les différentes valeurs (avec printf() ). Et tu regardes si elles sont correctes.
Tu regardes aussi bien attentivement ce que tu as écris en essayant de voir si ton code fait bien ce que tu penses avoir codé.
Une fois que tu as trouvé la zone où se produit l'erreur, tu essayes de bien comprendre ce qui ne vas pas et tu nous reposte le petit bout de code ainsi que ce qu'il doit faire

Citation:

---

Théoriquement, avec l'opérateur '&&', dès la première condition fausse, il s'arrête et ne regarde pas la seconde condition.
Mais avec certains compilateur, il regarderait quoi qu'il advienne les deux conditions.

---

Non, c'est dans le standard : la suite n'est pas évaluée. Si il ne fait pas ça, ce n'est pas un compilateur C.