]> Creatis software - gdcm.git/commit
* Memory leak hunt with the following command:
authorfrog <frog>
Mon, 14 Jun 2004 08:35:35 +0000 (08:35 +0000)
committerfrog <frog>
Mon, 14 Jun 2004 08:35:35 +0000 (08:35 +0000)
commitd569212ce5d0577c01b30796b288aafc2ae4fd9d
tree9a04ac774ca98b8d950ad51b7a17e276dd10e85f
parent98ab91206c2a0e603d6d9b11951860e5c78e315a
* Memory leak hunt with the following command:
      valgrind --leak-check=yes --leak-resolution=high --num-callers=40
               --show-reachable=yes gdcmTests PrintDocument
      It looks like many (all?) leaks are due to the STL (or a bad usage
      of the STL. The lines producing the leaks now have a comment with
      a "MEMORY LEAK" tag: you can retrieve them with
          grep "MEMORY LEAK" src/*
      Here are two typical examples which I can't help fixing:
      -----
          #include <string>
          int main() {
             std::string name;
             char * test = "babo";
             name = test;    //// <--- valgrind detects 960 bytes lost in
                             ////   call to std::string::operator=(char const*)
             name.clear();   //// Doesn't help !
             return 0;
          }
      -----
          #include <string>
          #include <iostream>
          int main() {
             std::string line;
             std::cout << "Type a bunch of characters followed by RETURN: ";
             getline(std::cin, line);   //// <--- valgrind dectects a loss
                                        //// of 1320 bytes in call to
                                        /// std::basic_istream<>& std::getline<>
             return 0;
          }
      -----
ChangeLog
gdcmPython/gdcm.i
src/gdcmCommon.h
src/gdcmDict.cxx
src/gdcmDictSet.cxx
src/gdcmSeqEntry.h
src/gdcmTS.cxx