[Dcmlib] Amélioration des Memory leak

[Jean-Michel Rouet]

> Benoit,
> Ca marche chez toi:
> 
> ctest -R TestCopy 

non mais c'est normal.
Maintenant que l'on copie les champs d'une image a l'autre, les deux images partagent le meme pointeur de donnée !!! 
Du coup, si on appelle les destructeurs de 'original' ET de 'copy' alors on va effacer deux fois la meme zone mémoire.
Je ne sais pas d'ailleurs si le parsing tag par tag avec l'iterateur effectue ou non la copie de l'image, ou si seule la fonction SetImageData en est la cause !

Conclusion/proposition: 
La fonction SetImageData est tres dangereuse !
La zone mémoire correspondant a compressed, qui normalement est allouée par PixelConverter ne devrait etre mise a jour que par PixelConverter. Si on donne ou nouvelle image, on fait une copie du contenu et pas du pointeur. Si la taille est plus grande ou plus petite ou réalloue. et on s'arrange pour que le destructeur de PixelConverter et celui de Document qui efface tagHT champ par champ ne se marchent pas sur les pieds. (comment ??? a priori comme cela vient d'etre proposé, a savoir tagHT efface les elements les uns apres les autres, et PixelConverter n'efface pas Decompressed ou RGB truc).

Commentaires ?

JM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20041116/348b8dcf/attachment.html>