topic Re: Memory leak when calling DFT from secondary thread in Intel® oneAPI Math Kernel Library

Memory leak when calling DFT from secondary thread

daniel_flassig — Thu, 17 Jul 2008 15:57:55 GMT

Hello,
I'm suffering from a little memory leak here:

I'm using Intel MKL 10.0.3,
MSVC++ 2005 (Microsoft Compiler).

I link statically to
mkl_intel_thread.lib,
libiomp5mt.lib

I do not use OpenMP in the rest of the project. I do not manually set the number of threads to use.

The startup thread is responsible for the user interface. One worker thread (created with _beginthreadex) calls
DftiCreateDescriptor(...)
DftiSetValue(...)
...
DftiCommitDescriptor(...)
and then executes a the fourier transforms many times.

In the end I get memory leaks, most of them originating from
__kmp_allocate_team >> __kmp_print_storage_map_gtid (typically are 148 or 160 bytes each)

For testing purposes I called the fourier transform code directly from within the startup thread and didn't get any memory leaks.

I appreciate any helpful hints
Best regards
Daniel

Re: Memory leak when calling DFT from secondary thread

daniel_flassig — Thu, 17 Jul 2008 17:31:30 GMT

Hello,
Thanks Ben.
I actually knew about the buffers that were not freed. When I said there were no leaks when the DFT was called from the primary thread, that meant none except for the lazily freed buffers.
It was because there were significantly more leaks (and leaks with a different allocation path), when the DFT was called from a secondary thread, that I posted this topic. The amount of additional leakage is however constant in a sense that it seems not to depend on how often the DFT is called from the secondary thread.
Best regards
Daniel

Re: Memory leak when calling DFT from secondary thread

daniel_flassig — Fri, 18 Jul 2008 13:06:08 GMT

Here is a minimal example, that reproduces the behavior. Notice the difference in dumped memory when running with/without the RUN_IN_PRIMARY_THREAD define.

I'm using Compuware DevPartner for Visual C++ (Version 8.2) for error detection.

Daniel

P.S. I'm linking to the dll version of the C standard library.