- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page