It was move from IPP forum. http://redfort-software.intel.com/en-us/forums/showthread.php?t=106951
I have two Windows 7 SP1 x64 dev machines that have reliability problems unless I set KMP_ALL_THREADS environment variable. If I don't set that environment variable, I get application crashes in Windows save (as) file dialogs. When the app crashes, it pops a separate console window to display errors. The errors I see are like this:
OMP: Error #136: Cannot create thread.
OMP: System error #8: Not enough storage is available to process this command.
And then the application crashes. The applications that have crashed like this are Outlook Express, VirtualDub, Visual Studio 2010, and a tiny C++ test ui I wrote that just opens a file save dialog. These machines both have 8GB of RAM, I am not low on RAM according to task manager. I have generally had only Visual Studio running.
When I execute the test ui and point to a directory without a jpeg, it works fine. When I point to a directory with a jpeg (as the above steps do), it crashes and pops a console window with this:
OMP: Error #136: Cannot create thread.
OMP: System error #8: Not enough storage is available to process this command.
OMP: Error #178: Function GetExitCodeThread() failed:
OMP: System error #6: The handle is invalid.
When I run under the visual studio debugger I don't get the crash.
The crash is perfectly repeatable, I haven't seen it not crash given the specified run conditions.
If I set the system environment variable KMP_ALL_THREADS (I tried 0,1,16 and 4096) or OMP_THREAD_LIMIT the crash does not happen. With system environment variable OMP_NUM_THREADS set to 1 or 16 the crash still happens. With system environment variable KMP_STACKSIZE and/or OMP_STACKSIZE set to 4m the crash still happens.
But when I set KMP_ALL_THREADS to 1, 16, or 4096 (probably anything) I get this when I run another app that uses IPP:
OMP: Warning #96: Cannot form a team with 8 threads, using 1 instead.
OMP: Hint: Consider unsetting KMP_ALL_THREADS and OMP_THREAD_LIMIT (if either is set).
So I either have crashes and a console window with errors with windows file save as dialog, or a console window with errors on an app that uses IPP. Neither is good.
What is going on here? Is Windows using Intel OMP? What does "not enough storage" mean if I'm not low on memory or disk? Why can it not form a team of 8 threads with KMP_ALL_THREADS set to 4096?
Link Copied
Some time ago I had a similar problem with a stress test-case ( based on TBB library ) and it was creating hundreds of threads.
In order to create as many as possible threads I used the following settings for the linker:
...
#pragma message ( "*** New HEAP Commit:Reserve and STACK Commit:Reserve Values Defined ***" )
#ifdef _DEBUG
// Case 1
// #pragma comment( linker, "/HEAP:1069547520,1069547520" )
// #pragma comment( linker, "/STACK:4194304,4194304" )
// Case 2
// #pragma comment( linker, "/HEAP:134217728,134217728" )
// #pragma comment( linker, "/STACK:134217728,134217728" )
// Case 3
// #pragma comment( linker, "/HEAP:268435456,268435456" )
// #pragma comment( linker, "/STACK:268435456,268435456" )
// Case 4
#pragma comment( linker, "/HEAP:536870912,536870912" )
#pragma comment( linker, "/STACK:536870912,536870912" )
#endif
#ifdef NDEBUG
// Case 1
// #pragma comment( linker, "/HEAP:1069547520,1069547520" )
// #pragma comment( linker, "/STACK:4194304,4194304" )
// Case 2
// #pragma comment( linker, "/HEAP:134217728,134217728" )
// #pragma comment( linker, "/STACK:134217728,134217728" )
// Case 3
// #pragma comment( linker, "/HEAP:268435456,268435456" )
// #pragma comment( linker, "/STACK:268435456,268435456" )
// Case 4
#pragma comment( linker, "/HEAP:536870912,536870912" )
#pragma comment( linker, "/STACK:536870912,536870912" )
#endif
...
All my tests were done on a 32-bit Windows XP.
Best regards,
Sergey
Here is a link to a thread:
Stress testing of Intel OpenMP library - More than 18,600 OpenMP threads created in a parallel region
http://redfort-software.intel.com/en-us/forums/showthread.php?t=105139&o=a&s=lr
Please take a look.
Best regards,
Sergey
For more complete information about compiler optimizations, see our Optimization Notice.