Memory leak on HelloWord? about simpleelastix HOT 22 CLOSED

Thanks for reporting!

from simpleelastix.

Will you fix this? This leak makes SimpleElastix useless for large projects :-(

from simpleelastix.

Yes, this needs to be fixed. Would be willing to dive into the code and help locate the problem?

from simpleelastix.

Yep! Already doing that, but unfortunately I am not a C++ expert... Hints/tips where to look are welcome.

from simpleelastix.

Great! Sure, are you on the SimpleElastix branch or the develop branch?

from simpleelastix.

I am on the SimpleElastix branch.

from simpleelastix.

Great! The first step would be to find out if the source of error is elastix or SimpleElastix (using the command line program is unfortunately not gonna help us because the OS releases all memory, also the leaked, when the program exits and restarts). Comment out this line and rerun your experiment (you may have to return an empty Image() to quelch compiler complaints about return values).

If the leak goes away, step into the ExecuteInternal function and experiment with commenting out lines or use an IDE to inspect the runtime stack. If you find the leak goes away when execution of elastix is commented out (these lines), the problem is elastix and we have to bring out the heavy artillery or possibly involve the original elastix authors.

If the leak is still there, the problem is with SimpleElastix. Good! We can fix it ourselves. Next place too look would probably be setters of images or other places where memory is allocated.

Let me know how it goes!

from simpleelastix.

Recompiled with line 420 commented out, as you suggested. The leak is still there. I'm investigating further...

from simpleelastix.

Update: my previous evaluation was wrong :-(
Due to several versions of SimpleElastix, the recompilation did not overwrite the previous version, so changes were not reflected.
After a manual cleanup and disabling line 420 on sitkSimpleElastix.cxx (and corresponding line 84 in sitkSimpleTransformix.cxx) DID fix the memory leak. Using Big Guns like Valgrind is unfortunately beyond my capabilities.

I am working on a manual SimpleElasyix install with the latest ITK/Elastix versions. There are quite a few issues there... Will keep you informed

from simpleelastix.

Update #2:
Made a manual build using ITK 4.10 an Elastix Trunk version (this is the only version I could get to compile) and SimpleElastix. The good news is that the memory leak is much smaller, the bad news is that it is still there. Now I can make approx. 100 iterations over transformix.Execute(). The SuperBuild configurartion only allows for 10 iterations (on a 16Gig Ubuntu using a 6Mb 8bit picture). I am out of options, any help is very much appreciated.

from simpleelastix.

Thank you for the very helpful report. I will take a look at the remaining leaks.

from simpleelastix.

The problem is definitely in transformix. I have made an attempt to debug it, here is the report:
http://www.xyz-imaging.com/elastix/memcheck_log.xml
(it's 2.9Mb!) The interesting part is at the end, that's where the largest memory leaks are reported.
Very interested in your comments...

from simpleelastix.

Sorry for the late response, the new release contains lots of fixes, also to the elastix library itself. Would you be interested in running your tests again?

from simpleelastix.

Kasper,
Can't get the SuperBuild to compile. Tried excluding BUILD_EXAMPLES and BUILS_TESTING, but the
error is always the same. Attached is the CMakeError.log.
Thanks
CMakeError.txt

Sorry for the late response, the new release contains lots of fixes, also to the elastix library
itself. Can you run your test again?

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#22 (comment)

from simpleelastix.

The error seems to stem from CMake's own checks of the host system. What OS and compiler version are you using?

from simpleelastix.

I'm using Ubuntu 14.04, gcc 4.82, CMake 2.8.12.
Previous SuperBuild compiled fine with these...

The error seems to stem from CMake's own checks of the host system. What OS and compiler version
are you using?

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#22 (comment)

from simpleelastix.

The problem seems to be that the file
/root/src/eclipse_develop/SimpleElastix/CMake/sitkSourceVersionVars.cmake is missing.

I have manually created it from the sitkSourceVersionVars.cmake.in file. After that, the compiler
reports:

/root/src/eclipse_develop/SimpleElastix/Code/Elastix/src/sitkSimpleTransformix.cxx: In constructor
‘itk::simple::SimpleTransformix::SimpleTransformix()’:
/root/src/eclipse_develop/SimpleElastix/Code/Elastix/src/sitkSimpleTransformix.cxx:34:9: error:
‘class itk::simple::SimpleTransformix’ has no member named ‘m_SetOutputDirectory’
this->m_SetOutputDirectory = "";
^
/root/src/eclipse_develop/SimpleElastix/Code/Elastix/src/sitkSimpleTransformix.cxx:35:9: error:
‘class itk::simple::SimpleTransformix’ has no member named ‘m_SetLogFileName’
this->m_SetLogFileName = "";

Hope this helps.

The error seems to stem from CMake's own checks of the host system. What OS and compiler version
are you using?

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#22 (comment)

from simpleelastix.

This error was just corrected and can be fixed by doing a git pull 😊 The first sitkSourceVersionVars error you mention I cannot reproduce, but I do recall that there has been issued with this. I am currently trying to reproduce it on Ubuntu 14.04 with GCC 4.8.4. Will let you know what I find out. Also let me know if you have more problems.

from simpleelastix.

The current git poll still contains the missing sitkSourceVersionVars.cmake error. After creating
it manually, compiling fills up entire memory (16Gig!) + 5Gig swap (!). Still unable to compile,
but after excluding BUILD_TESTING from cmake, compiling is OK!

Even better news: the memory leak is fixed! Thanks a lot, great job!

This error was just corrected and can be fixed by doing a git pull 😊 The first
sitkSourceVersionVars error you mention I cannot reproduce, but I do recall that there has been
issued with this. I am currently trying to reproduce it on Ubuntu 14.04 with GCC 4.8.4. Will let
you know what I find out. Also let me know if you have more problems.

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#22 (comment)

from simpleelastix.

This version throws a lot of AttitbuteErrors in SimpleITK.py line 69:
AttributeError: type object 'object' has no attribute '__getattr__'

Happens in:

• LogToFolder
• LogToFolderOff
• SetInputImage

Possibly more, stopped testing here
Unfortunately I cannot run the tests on the package, since the do not compile (as explained before)

from simpleelastix.

You can reduce the memory requirements by changing line 22 of SuperBuild/External_Elastix.cmake from

-DUSE_ALL_PIXELTYPES:BOOL=ON

to

-DUSE_ALL_PIXELTYPES:BOOL=OFF

This will make elastix use only float for 2D images, float and short for 3D images and short for 4D images. With the setting set to ON (default), all eight supported pixel types are compiled for all dimensionalities, which is why the memory requirements are so big. You can use the SimpleITK CastImageFilter to cast your images into these types if necessary.

As for the missing functions, these have changed name in the new version. I apologize for the inconvenience, but hopefully these changes will make the API more intuitive for new users. SetInputImage() has changed name to SetMovingImage() more accurately describe its role and its associated image definitions. LogToFolder() has been replaced with SetOutputDirectory() and LogToFileOn/Off(). This allows for more fine grained control over elastix outputs, and (hopefully) works better now that the deformation field, jacobian and determinant of jacobian can be written to disk in addition to the log file.

from simpleelastix.

That explains it! Looks like everything works fine now. Thanx!

from simpleelastix.