memory leakage using fft and MKL_FreeBuffers

[andipandi]

Dear Board!

I know that there have been several posts here about this topic, but I wonder how you can properly search for memory leaks in your own code if the debugger reports masses of memory leaks in the MKL?

I am using the MKL to compute a simple FFT, using

DftiCreateDescriptor

DftiCommitDescriptor

DftiComputeForward

DftiComputeBackward

Then I use the

Status = DftiFreeDescriptor(&Desc_Handle);

and

MKL_FreeBuffers();

functions.

Even if you say that everything is fine (speed reasons, whatever) with your leaks, they would completely cover my own leaks, since I am also used to not having any leaks, and if so, to try to eliminate them.

I am grateful for any suggestions!

[Vladimir_Lunev]

Hi!

Thank you for the important question! MKL shouldn't have memory leaks after MKL_FreeBuffers() in case of the correct usage.
As I can see, your code is correct in common. So, to investigate the problem I need more detailed info.

Which MKL version do you use? If it's possible, please run MKL example from the directory example/versionquery in your MKL package.
Use one of commands:
>nmake lib32 | dll32 | libem64t | dllem64t | lib64 | dll64 on Windows
>make lib32 | so32 | libem64t | soem64t | lib64 | so64 on Linux
depending on your system and type of MKL - static or dynamic. The results can be found in the directory example/versionquery/_results.

Can you give us your exact testcase with the linker command line (or MS project) which demonstrate memory leaks in MKL?

Many thanks,
Vladimir
MKL library engineering

[andipandi]

Hi!

Thx for your reply!

I am using MKL 10.0.0.15.

I tried making a small sample project to show the problem to you, and to my surprise found out that there were no mem leaks.

Then I proceeded to change my original project (MKL is statically linked to a .dll which is used by another .exe program), and noticed that the problem comes with an exit(0) that comes right after doing the FFT (I was debugging the function and added a call to it in the startup-routine of the program, and in order not to spend too much time or even mix this code into release code :) I added the exit(0); in order to notice straight away.

Anyhow, this seems to cause the problem (also, with the exit(0) and no fft, there are no mem leaks). I don't really plan on using the exit(0) in a later version, so the problem is actually no problem for me any more, maybe for you if you want to do some more testing on this.

Best regards