You need to generate your VS solution using CMake. Look at this about how to include MFC support.
Otherwise you will need to create an ITK hello world example using CMake and then copy VS settings (include paths, libraries etc) to your custom VS solution, which is annoying and error prone.
Is there any full example on how to do that? I’m not expert about CMake so I don’t know what is the simplest way to do that. Can you suggest any link?
Keep in mind that with the previous versions of ITK I didn’t have any memory leaks, and the usage was the same….building ITK shared libs using CMake and then adding include libraries/header files in my MFC custom application.
Tks,
Lorenzo
Are you able to get more details about the object that are leaking, or where they are allocated?
Hi blowekamp,
I tried a simple default console application using VS2015 (New Project/Win 32 Console application) and left all default configuration properties. So without using MFC.
Then I added the dependencies on ITK (built with CMake with its default configuration as downloaded by the website). So the additional include folder and the additional input libraries with all the list of the .lib from itk.
Finally I added the following lines before the main section
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
and the following line before exit from the main section
_CrtDumpMemoryLeaks();
in order to get the memory leaks.
Last thing I added #include “itkImageFileReader.h” after #include “stdafx.h”
Then I get memory leaks (just including the file).
How’s that possible?
This means instead of memory addresses get names and/or types of variables getting leaked, and lines of code where they were allocated.
Try running it in debug mode, if you are not already doing that.
Sorry guys, maybe I was not clear. I am attaching the console application that gives me the memory leaks. I didn’t use anymore MFC in order to isolate the problem.
In order to build it you should have Visual Studio 2015. I am working on Windows 10.
Of course, before building you should replace the additional include directories and additional include libraries with your ITK 5.0.1 path.
Let me know if you can have the leaks.
Tks very much
LorenzoConsoleApplication1.zip (5.7 KB)
Highly likely itkImageFileReader can not work without Cmake, some files should be generated. You could try after inlude itkImageFileReader.h
#include itkImageIOFactoryRegisterManager.h
itkImageIOFactoryRegisterManager.h (3.2 KB)
I didn’t test, i use Cmake and recommend it.
Edit: also look at the end of itkImageFileReader.h file
#ifndef ITK_MANUAL_INSTANTIATION
# include "itkImageFileReader.hxx"
#endif
#ifdef ITK_IO_FACTORY_REGISTER_MANAGER
# include "itkImageIOFactoryRegisterManager.h"
#endifHi Mihail,
I included the file you attached but doing so I got much much more memory leaks.
I didn’t create the solution of my project using CMake, because I don’t have this chance, since the solution already exists and I have to make only an upgrade of the ITK library.
I have another question: in my installed files of the ITK library I don’t have this itkImageIOFactoryRegisterManager.h….of course this file is present in the original source of ITK downloaded from the website. Why? I built ITK using CMake default configuration from the src files downloaded.
Is there any option in CMake to enable?
Tks
The file is not in source, it belongs to particular project and is generated.
Edit:
s. UseITK.cmake and comment
Hi Mihail,
I tried to rebuild ITK turning on the example buildling with CMake. Then I tried to run the “ImageReadWrite” example. Of course, in this case the solution was generated by CMake (not by me). I just added in the source file the lines of code needed to get memory leaks:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
and before exiting
_CrtDumpMemoryLeaks();
Same problem, same memory leaks. Could you please try and let me know if you have the memory leaks I found?
Thank you. I’ll try.
On Linux (Cmake, Debug build, default configuration, only disabled BUILD_TESTING) and program
#include "itkImageFileReader.h"
int main(int argc, char ** argv)
{
return 0;
}
Valgrind didn’t find leaks
=28897== Memcheck, a memory error detector
==28897== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==28897== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==28897== Command: ./mmm
==28897==
==28897==
==28897== HEAP SUMMARY:
==28897== in use at exit: 0 bytes in 0 blocks
==28897== total heap usage: 105,600 allocs, 105,600 frees, 5,707,785 bytes allocated
==28897==
==28897== All heap blocks were freed -- no leaks are possible
==28897==
==28897== For counts of detected and suppressed errors, rerun with: -v
==28897== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It will be little difficult to exactly reproduce on Windows, i only have VS 2013 currently (still build releases with ITK 4.13), but i’ll try.
Hi Mihail,
any news? I’m still having problems with memory leaks.
Regards
Can _CrtDumpMemoryLeaks(); have false positives?
Update:
I followed the example for manual registering IO factories and I have a lot of memory leaks in my console application on windwos 10.
Here is the code
#include "stdafx.h"
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include "itkImageFileReader.h"
#include "itkMetaImageIOFactory.h"
using namespace itk;
int main()
{
const char * metaImageFileName = "file.mha";
constexpr unsigned int Dimension = 3;
typedef unsigned short PixelType;
typedef itk::Image<PixelType, Dimension> ImageType;
typedef itk::ImageFileReader<ImageType> ReaderType;
ReaderType::Pointer reader = ReaderType::New();
using RegisteredObjectsContainerType = std::list<itk::LightObject::Pointer>;
RegisteredObjectsContainerType registeredIOs = itk::ObjectFactoryBase::CreateAllInstance("itkImageIOBase");
reader->SetFileName(metaImageFileName);
itk::MetaImageIOFactory::RegisterOneFactory();
try
{
reader->Update();
std::cout << "succeed.\n" << std::endl;
}
catch (itk::ImageFileReaderException & error)
{
std::cerr << "Error: " << error << std::endl;
return EXIT_FAILURE;
}
system("PAUSE");
_CrtDumpMemoryLeaks();
return 0;
}
Tks everybody
I just tried your code (with commenting out stdafx.h):
//#include "stdafx.h"
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include "itkImageFileReader.h"
#include "itkMetaImageIOFactory.h"
using namespace itk;
int
main()
{
const char * metaImageFileName = "C:/a/image_corrUC.mha";
constexpr unsigned int Dimension = 3;
typedef unsigned short PixelType;
typedef itk::Image<PixelType, Dimension> ImageType;
typedef itk::ImageFileReader<ImageType> ReaderType;
ReaderType::Pointer reader = ReaderType::New();
using RegisteredObjectsContainerType = std::list<itk::LightObject::Pointer>;
RegisteredObjectsContainerType registeredIOs = itk::ObjectFactoryBase::CreateAllInstance("itkImageIOBase");
reader->SetFileName(metaImageFileName);
itk::MetaImageIOFactory::RegisterOneFactory();
try
{
reader->Update();
std::cout << "succeed.\n" << std::endl;
}
catch (itk::ImageFileReaderException & error)
{
std::cerr << "Error: " << error << std::endl;
return EXIT_FAILURE;
}
system("PAUSE");
_CrtDumpMemoryLeaks();
return 0;
}
… and I get no memory leaks:
succeed.
Press any key to continue . . .
Press any key to continue . . .
If I don’t comment the first line, I get: C:\Misc\Tester\tester.cpp(1): fatal error C1083: Cannot open include file: ‘stdafx.h’: No such file or directory
Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3
Windows 10 x64 Version 19.03
ITK-5.0.1 (built with static libraries - I don’t know whether that matters)
CMake 3.15.5 (but CMake version probably doesn’t matter)
Hi Dzenan,
tks! I don’t know why I still have the memory leaks.
Just one difference (I don’t know if it is a big difference), ITK 5.0.1 has been built has shared libraries (.dlls).
Could you please try this way?
Tks
This looks like a good blog on using this tool:
https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019
Note:
False positives
_CrtDumpMemoryLeaks can give false indications of memory leaks if a library marks internal allocations as normal blocks instead of CRT blocks or client blocks. In that case, _CrtDumpMemoryLeaks is unable to tell the difference between user allocations and internal library allocations. If the global destructors for the library allocations run after the point where you call _CrtDumpMemoryLeaks, every internal library allocation is reported as a memory leak. Versions of the Standard Template Library earlier than Visual Studio .NET may cause _CrtDumpMemoryLeaks to report such false positives.
At the point _CrtDumpMemoryLeaks() is run, even the reader smart pointer is not released much less dynamic library resources. I don’t think this tool will easily work with shared libraries and the complicated order of when static objects are destroyed across libraries.
I don’t think you are detecting a real problem.
With VS2019, and ITK-master af89589, built with shared libraries, I get no leaks either:
BMPImageIO : Magic Number Fails = O : b
succeed.
Press any key to continue . . .
C:\Misc\Tester\Debug\tester.exe (process 37516) exited with code 0.
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .
Hi Dzenan,
I am attaching a sample application.
Now I don’t use anymore a Win 32 Console Application but a single document MFC Application for x64.
In this way I don’t call _CrtDumpMemoryLeaks(); MFCApplication.zip (135.0 KB)
I have Windows 10 1903 and ITK 5.0.1 (the source .zip file downloaded from here https://itk.org/ITK/resources/software.html) built using CMake 3.15.3 for x64 platform using default options, the only custom option I used was to build as shared library and not as static library .
If you build the application, run and close in debug mode (of course) you should see the memory leaks I’m still having. Use the debug x64 for building the application.
In order to get the memory leaks I just added
#include “itkImageFileReader.h”
in the stdafx.h and I used this code
typedef ImageFileReader <Image<unsigned short, 3>> ReaderType; ReaderType::Pointer reader = ReaderType::New();
in the method
BOOL CMFCApplicationDoc::OnNewDocument()
In a previous answer you told me that you used Visual Studio 2015 community, so could you please try this application and tell me if you get the same memory leaks?
Tks a lot,
Lorenzo
P.S. naturally you have to change the directories (c++ and .lib) in the project settings.