I maked DLL with Intel C++ Compiler 11.1 and I maked application using this DLL.
Memory leaks seem to appear in OpenMP pragma line.
This leaks only occured using libiomp5md.lib.
DLL program code.
void test::__set(__int16 value, __int16* pDst, int num)
#pragma omp parallel for
for (int i = 0; i < num; i++)
pDst = value;
This is analyzation result of Parallel Inspector.
DLL.dll!___kmp_allocate - 0x0000dabc
DLL.dll!__kmp_free_thread - 0x00007edd
DLL.dll!__kmp_allocate_team - 0x0000885b
DLL.dll!__kmp_infinite_loop - 0x000091d3
DLL.dll!__kmp_register_root - 0x00002f85
DLL.dll!__kmp_internal_end_atexit - 0x00009d57
DLL.dll!__kmp_get_global_thread_id_reg - 0x00002b92
DLL.dll!__kmpc_global_thread_num - 0x000017e7
DLL.dll!__set - Math_main.cpp:18
07_Math.exe!main - main.cpp:25
Does the program leak when pragmas not there, just a serialized application? i.e, serialized by setting OMP_NUM_THREADS=1 , or commenting pragmas.. In that case, there could be some new-delete (or whichever complex API's out there) or class/resource destruction problem.
If it is caused by concurrency or multithreading (in this case by using Openmp), there could be some functions in the DLL that are not thread-safe or re-entrant. Or, there is a need ofconversion of some overlooked static variables to private variables with openmp, to prevent memory corruption.
Also, make sure you compile all bits of your application (DLL, exe, etc) & link using /Qopenmp (this I assume you are using). We recommend using libiomp5md.lib for a dynamic runtime link of Openmp..
It looks like without knowing the code of your DLLI could not help you more. Also, which tool you are using for verifying memory leaks.
Could you send zipped application, or the self-contained test-case, so that I could know better.
In case you are just using command-line, also let know of the command-line options while compile & linking.
I noticed from the program that you sent me several things:--
1. apple project is not using Intel Compiler. Convert it to use Intel C++
2. you are using in DLL project, the Input lib as libiomp5mt.lib , when already the /Qopenmp option includes libiomp5md.lib for you , because Openmp runtime is Dynamic by default. (To make it static runtime, you have to specify the /MT and /Qopenmp-link:static options. Thus, we are mixing the static & dynamic runtimes in your application.
3. You are also specifying /MT in Project Properties, while you need to specify /MD (for the reason as in 2), i.e., using the Dynamically Linked Libraries of openmp during link-time.
When I followed the 2) & 3) steps and modified the Properties in your program, it caused the Memory Leak to go away, and its clean now.
Hence, the mixing of various linking styles was the anomaly here.
Generally speaking, The use of static OpenMP libraries is not recommended, because they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results.
Please let me know whether you observe the same thing.
2) Also remove the /MT in both app & DLL, and instead specify /MD option for dynamic linking.
Above steps atleast for me caused the Memory Leak to go away.
When I keeped using libiomp5mt.lib link, and specifyed /MT and /Qopenmp-lin:static, I confirmed memory leak is not cleared.
When I changed libiomp5mt.lib to libiomp5md.lib, I confirmed memory leak is cleared.
When I delete libiomp5mt.lib, and specifyed /MD, I confirmed memory leak is cleared.
But, I want to use libiomp5mt.lib.
Because We make DLL as business purpose, so we cannot use Dynamic Linked Libraries provided Intel C++ Compiler package.
There is the way which we keeped usgin libiomp5mt.lib and memory leak is cleared?
which talks about deprecating the static versions of Openmp libraries. which is also said in Compiler User guide, to avoid usage of static version of openmp libraries. Dynamic version of openmp is stronly recommended, and that would only remain in future versions.
The reason is:--
1.if you use static linking of openmp libraries in both app & DLL, it links the libiomp5mt.lib , probably twice.
2. If you specify static-link only in DLL, (but you have to specify /Qopenmp in the app, more so if the main app has openmp pragmas to recognize them), then you will end up with static & dynamic version of openmp.
Both will give some fault suggesting duplication, and things may go wrong leading to fault or abort.
The notion is to use only dynamic openmp , so only using /Qopenmp option, and not specifying any explicit libraries of openmp anywhere..
For the application to work at user-end, the libiomp5md.dll dynamic version should be present to make it work.
There are 2-ways to make it work at user end.
1. The Redistributable Library packages are based on compiler version + architecture.
For example, on Intel(64) architecture, we have:
w_cproc_p_11.1.048_redist_intel64.exe, which matches the posted compiler w_cproc_p_11.1.048_intel64.exe. They would contain redistributable libraries.
2) The 2nd method lies in distributing the packages required under something like:-- C:\Program Files (x86)\Intel\CompilerPro-12.0\redist\ia32\compiler , which has libiomp5md.dll openmp library.
All other methods (like static runtime) would fail desparately, and should be tried at user's own risk.
You are using /Qopenmp-lin:static, this seems wrong. Please use /Qopenmp-link:static instead.
Milind is right. The use of static OpenMP libraries is not recommended because they might cause multiple libraries to be linked in an application and could lead to unpredictable results. If you insist that you need to use static linking, you should be ready to debug. It is your call.