Memory leaks istanziating itkImageFileReader in MFC

#1

Hi,
I have implemented an MFC application using VS2015 and ITK 5.0.1.
I don’t understand why just istanziating an itkImageFileReader object I get some 8 bytes memory leaks.
Can anyone help me?
Thanks in advance,
Lorenzo

#2

Hi Lorenzo,

Welcome to the ITK community! :sunny:

To understand your problem, please share a Short, Self Contained, Correct (Compilable), Example.

Without looking at the code, it is important to now that the output should be assigned to ImageFileReaderType::Pointer, which is an itk::SmartPointer. The smart pointer will delete the object it owns when it goes out of scope.

#3

Hi Matt,
thanks for your answer.
I tried with a console application too and I Always got memory leaks.
This is a code example that I used:

#include "stdafx.h"

#include "itkImageFileReader.h"

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int main()
{
  system("PAUSE");
    
  _CrtDumpMemoryLeaks();

  return 0;
}

As you see in this main I don’t do anything. Just including iktImageFileReader I get the following memory leaks in the output window:

Detected memory leaks!
Dumping objects ->
{158} normal block at 0x0000022B5135C0A0, 16 bytes long.
 Data: < Xy             > 10 58 79 8B F6 7F 00 00 00 00 00 00 00 00 00 00 
{157} normal block at 0x0000022B5135E390, 40 bytes long.
 Data: <  5Q+     5Q+   > 90 E3 35 51 2B 02 00 00 90 E3 35 51 2B 02 00 00 
{156} normal block at 0x0000022B5135C050, 16 bytes long.
 Data: < Wy             > F8 57 79 8B F6 7F 00 00 00 00 00 00 00 00 00 00 
{155} normal block at 0x0000022B5135E630, 40 bytes long.
 Data: <0 5Q+   0 5Q+   > 30 E6 35 51 2B 02 00 00 30 E6 35 51 2B 02 00 00 
{154} normal block at 0x0000022B5135BFB0, 16 bytes long.
 Data: <@ 6Q+           > 40 19 36 51 2B 02 00 00 00 00 00 00 00 00 00 00 
{153} normal block at 0x0000022B513396B0, 112 bytes long.
 Data: <  3Q+     3Q+   > B0 96 33 51 2B 02 00 00 B0 96 33 51 2B 02 00 00 
{152} normal block at 0x0000022B5135C8C0, 16 bytes long.
 Data: <( 6Q+           > 28 19 36 51 2B 02 00 00 00 00 00 00 00 00 00 00 
{151} normal block at 0x0000022B5133B990, 112 bytes long.
 Data: <  3Q+     3Q+   > 90 B9 33 51 2B 02 00 00 90 B9 33 51 2B 02 00 00 
{150} normal block at 0x0000022B5135BA10, 16 bytes long.
 Data: <  6Q+           > 10 19 36 51 2B 02 00 00 00 00 00 00 00 00 00 00 
{149} normal block at 0x0000022B5133A390, 112 bytes long.
 Data: <  3Q+     3Q+   > 90 A3 33 51 2B 02 00 00 90 A3 33 51 2B 02 00 00 
{148} normal block at 0x0000022B51361910, 72 bytes long.
 Data: <  5Q+     3Q+   > 10 BA 35 51 2B 02 00 00 90 A3 33 51 2B 02 00 00

Let me know what I am doing wrong. I built Itk 5.0.1 using Cmake 3.15.3 with the default configuration.
Regards,
Lorenzo

#4

Did you use CMake to generate the Visual Studio solution? Why do you have #include "stdafx.h"?

#5

Hi Dzenanz,
thanks for you interest! No, I didn’t use CMake for the simple console application attached in the example.
I generated it using VS2015 with the default configuration. In fact, by default the #include “stdafx.h” has been inserted by the compiler. I cannot remove it, otherwise it doesn’t build. In the stdafx.h I just have the following lines of code:

#pragma once
#include "targetver.h"
#include <stdio.h>
#include <tchar.h>

and inside the targetver just this line:

#pragma once
#include <SDKDDKVer.h>

Any ideas?
Regards,
Lorenzo

#6

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.

#7

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

#8

Are you able to get more details about the object that are leaking, or where they are allocated?

#9

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?

#10

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.

1 Like
#11

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)

#12

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"
#endif
#13

Hi 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

#14

The file is not in source, it belongs to particular project and is generated.
Edit:
s. UseITK.cmake and comment

1 Like
#15

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?

#16

Thank you. I’ll try.

#17

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.

1 Like