[Dcmlib] gdcm version 0.6: correction

[Jean-Michel Rouet]

Au risque de me repeter, s'il y a un debordement de tableau (Array bound write), il est fort probable que cela passe sans probleme apparent, puis que ca plante "bizarrement" ailleurs, exemple dans la stl ou dans un simple cout... 
La premiere des choses a verifier lorsqu'on a un plantage bizarre c'est justement si on a pas de buffer overflow. Or, dans ce cas précis, je suis sur que c'est le cas.
Peux tu revérifier ca (PixelConverter->Decompressed est alloué en 256*256*2, puis remplit avec des données sur 256*(256+2)*2, donc tu ecrases des données apres Decompressed, et ca peut etre n'importe quoi comme rien du tout).

JM



Benoit Regrain benoit.regrain at creatis.insa-lyon.fr 
Wed Nov 10 17:22:50 CET 2004 

  a.. Previous message: [Dcmlib] gdcm version 0.6: correction 
  b.. Next message: [Dcmlib] Message for Dennis 
  c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

--------------------------------------------------------------------------------

Je viens de m'occuper de ce problème. TestReadWriteReadCompare normalement passe.


Par contre, j'ai toujours des problèmes avec le ShowDicom...
J'ai constaté le phénomène suivant :
 - on récupère la HashTable des tags du header (par référence... tres important) : méthode GetTagHT
 - on essaye de parcourir cette hash table et cela plante.

Si on essaye de passer la hash table par copie (donc sans la référence) alors cela plante directement
à l'appel de cette méthode. J'avais déjà vu cela concernant les objets de la STL avec MSVC6 (toute 
plateforme confondue). Et c'etait dû à des problèmes de link incremental.
Si quelqu'un en sait plus la dessus... je suis preneur de toute information. Merci.


Benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20041110/9784180f/attachment.html>