To get product updates, log in to the Intel® Software Development Products Registration Center

For questions or technical support, visit Intel® Software Developer Support

Version 2011 SP1 Initial release, September 6, 2011: release_notes_studio.pdf

Using both of these technologies at the same time has the following implications...

• Binaries under analysis of Inspector may be interrupted by dialogue boxes
  • Press the "ignore" button- execution will continue (recommended action) - note: you may have to press "ignore" multiple times - as by default this dialogue box will appear every so many instances for each unique error detected.
  • Do not press the "abort" button - as that will exit the application before Intel Parallel Inspector can give you a list of all memory errors, and Intel Parallel Inspector may report false positives as your application exited prematurely.
  • Do not press the “retry” button in the dialog box, else - the debugger will open and point you to assembly code that was "generated" as a result of running your application under the  Inspector analysis engine rather than the assembly of your application (not recommended)
• The same issue may be reported by both technologies.
• Performance will suffer as both technologies are tracking and checking memory usage

You may want to turn off the Debug Heap Manager provided by the Microsoft C runtime library.

There is only one way to "turn off" the debug heap manager... and that is:

•   Use the Release/Base version of the Microsoft C runtime library by compiling with either /MD or /MT

In the ideal situation, it is recommended that you use /Od with memory error analysis in Intel Parallel Inspector with the /MD or /MT runtime library selections. By default a "debug" configuration in Visual Studio will select /MDd or /MTd settings rather than the /MD or /MT settings. You would need to check these settings for each project in your solution.  Note: It can be difficult to accomplish this on large projects - as it will be difficult to have the same runtime library used in your entire application (all dll(s), lib(s), etc).

Another way, to work around this problem - is to tell the "debug" version of the heap manager to disable heap checking and reporting (tracking still occurs with this method).  This can be done using the _CrtSetDbgFlag api.  An example follows showing a code snippet which turns these features off.

#include <crtdbg.h>

main() {

int oriDbgFlag, newDbgFlag;

oriDbgFlag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);

newDbgFlag &= ~_CRTDBG_ALLOC_MEM_DF; //Turn this off (by default it is on)

newDbgFlag |= _CRTDBG_CHECK_ALWAYS_DF;  //Turn this on (by default it is off)

newDbgFlag &= ~_CRTDBG_CHECK_CRT_DF;  //Not needed as this is default

newDbgFlag &= ~_CRTDBG_DELAY_FREE_MEM_DF; //Not needed as this is default

newDbgFlag &= ~_CRTDBG_LEAK_CHECK_DF; //Not needed as this is default

newDbgFlag = (newDbgFlag & 0x0000FFFF) | _CRTDBG_CHECK_DEFAULT_DF; //Not needed as this is default

newDbgFlag = _CrtSetDbgFlag(newDbgFlag);

//...

For more information look for _CrtSetDbgFlag at MSDN.

Potential dialogue boxes/messages that the debug heap manager of the Microsoft C runtime library may produce, which can be suppressed using the techniques above (when under analysis of Intel Parallel Inspector):

Client hook allocation failure at file

Client hook allocation failure %hs line

Invalid allocation size:

Error: memory allocation: bad memory block type.

Client hook re-allocation failure at file %hs line.

Client hook re-allocation failure Or Error: memory allocation: bad memory block type.

Error: memory allocation: bad memory block type. The Block at 0x%p was allocated by aligned routines, use _aligned_realloc(). The Block at 0x%p was allocated by aligned routines, use _aligned_free()

Client hook free failure. HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p. CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

_heapchk fails with _HEAPBADBEGIN.

_heapchk fails with _HEAPBADNODE.

_heapchk fails with _HEAPBADEND.

_heapchk fails with _HEAPBADPTR.

_heapchk fails with unknown return value!

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

%hs located at 0x%p is %Iu bytes long.

Bad memory block found at 0x%p.

Detected memory leaks!

Damage before 0x%p which was allocated by aligned routine

One of the main goals of Threading Errors analysis in Parallel Inspector is detecting data races which potentially lead to improper operation of applications or data corruption. Sometimes the code constructions that provoke data races are hidden in the complicated implementation of the program and Parallel Inspector is the best tool to help find such constructions.

However, there are some corner cases when an obvious problem in the implementation is not detected despite a sufficiently intrusive analysis. One such case is the parallel code sample below.

#include <omp.h>
int g_var;
void TestFunc(int par)
{
      printf("Thread# %d \n", omp_get_thread_num());
      if (par == 0)
            g_var++;
      if (par != 0)
            g_var--;
}
 
int main(int argc, char* argv[])
{
      omp_set_num_threads(2);
 
#pragma omp parallel for
      for (int i=0; i<2; i++)
            TestFunc(i);
 
      printf("%d \n", g_var);
return 0;
}

A few comments on the code:

- It's an OpenMP implementation of parallel execution of function TestFunc()

- TestFunc() is called once by each of the two threads

- Depending on input parameter one of the two branches is executed in the different threads incrementing or decrementing the global variable

- The global variable is not protected by any synchronization means

- The printf function call in the function  TestFunc() indicates that both threads are active.

The test case is compiled with Intel C++ Compiler v.10.1 and analyzed with Intel Parallel Inspector 1.0 Update 1 (build #66191) in the Treading Error level ti2. As it is shown on the screen shot with results of the analysis, the data race is not detected for this case. The level ti3 does not detect the error as well.

A persistent investigator would soon discover that Intel Thread Checker easily finds the error and reports the data race against the global variable. This confirms what we suspected, that there really is a data race here.

Intel Parallel Inspector offers various levels of intrusiveness in its analysis to balance time and resource use against the level of threading error detection. If ti4, the highest level is selected, this data race is detected as well.

Detection of this data race on levels ti2 and ti3 was skipped in order to improve analysis performance. One shortcut to significantly decrease overhead at these intermediate levels is to avoid checking for data races if memory is known to be shared among only two threads and only touched once by each. Even in that case there is a chance that Parallel Inspector will find a data race. It's dependent on the application. The corner cases like the sample above we believe are extremely rare in real applications. Slight modification of the code (setting more threads or adding more operations with the global variable) may change Parallel Inspector's ability to detect the data race on these intermediate levels.

As for performance improvement, a user might find Intel Parallel Inspector analyzing threading errors significantly faster on the intermediate levels by comparison to Intel Thread Checker.

But this is NOTfor Intel® Parallel Inspector, even if there are VtuneApi.h and VtuneApi.dll under the Parallel Inspector's directory. The user can try VtuneApi.h and VtuneApi.dll but they never work in your code. See below example:

......

(vtPause());

test_uninitialized_load();

test_out_boundary();

(vtResume());

mismatch_deallocation();

......

Actually Intel® Parallel Inspector will check all memory errors in above code, vtPause and vtResume are not effective. This is same for thread errors checking.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

The Parallel Inspector and the Parallel Amplifier have new options (plug-in) in Microsoft* Visual Studio* 2005/2008's  "Options" dialog, please see "Result Location" item under "Intel Parallel Inspector" and "Intel Parallel Amplifier", change it from "Save results in the Visual Studio* project default location" to "Save results in the directory:". Note that the user should specify a directory which already is existed.



2. Sometime the user starts the Parallel Inspector Analysis or the Parallel Amplifier Analysis, meanwhile the user wants to see separated Console application's running. The user can simply modify "Direct output for non-GUI application to:" from "Separate console windows" to "Microsoft* Visual Studio* output window".

After doing above change, the use can watch Analysis status and Console application's running simultaneously.