Use new Collection Control APIs in Inspector XE 2013

What are problems we have when using Inspector XE?

Intel® Inspector XE launches user's program then dynamically finds memory errors and threading errors, generate a report finally. The collector might cause significant overhead or extra data storage, if user's program is huge. There are several ways to reduce overhead or data storage.

Here are several test scenarios I experienced before, and hope to give developers idea to reduce overhead or provide a workaround.

• Scenario 1: If the developer worked on a big program, which includes executable and dynamic libraries. All dynamic libraries could be system libraries, development tool's libraries, 3rd party libraries and user’s libraries. Most of time, the developer cares of memory errors and threading errors in her/his source code. So only interest of module(s) is inspected by Inspector XE. For example:

Inspxe-cl -collect mi3 -module-filter-mode=include -module-filter=.\foo.exe -- foo.exe

Use Inspector XE to launch foo.exe, only interest of module named foo.exe will be traced and report errors.

 

Scenario 2: Similar as scenario 1, but the developer needs to know all errors from all modules, except some system libraries, such as msvcrt90.dll, kernel32.dll, etc. The developer can do:

Inspector -collect mi3 –module-filter-mode=exclude -module-filter=msvcrt90.dll,kernel32.dll --foo.exe

 

Scenario 3: The developer knew all old errors but code was changed daily. The developer wanted to know NEW errors only in code, and hope that Inspector doesn’t report old errors. Can work on this way:

Step 1. Inspects memory errors or threading errors first

inspxe-cl -collect mi3 –r myRes -- ./program

Step 2. Uses existing result directory to generate .sup file

inspxe-cl -create-suppression-file default.sup –result-dir myRes

Step 3. Tests new binary but filter old results

inspxe-cl -collect mi3 -suppression-file default.sup -r myRes1 -- ./program

 

Scenario 4: The developer worked on big 32bit application, static linking other modules into a big application, which consumed high memory. Using Inspector XE on this program to meet a crash, said "out-of-memory". The reason was that Inspector used extra data storage to track the status of memory access (or shared data access among threads), but total memory space was only 2GB limted in 32bit system. The developer can do one of below option:

a.       Port code from 32bit application to 64bit application to use 4GB memory address space. However it is not easier to do, if development environment has significant difference.

b.      Isolate some critical code to build a dynamical library. So uses method we mentioned above “-module-filter-mode=include” to inspect interest of module ONLY.

c.       Uses LARGEADDRESSAWARE. Add this into Linker options to build, or use “Editbin /LARGEADDRESSAWARE program.exe” to modify the binary, it allows the program to use memory space without 2GB restriction.

 

Finally, I can use new Collection Control APIs to solve all above issues. That is, use a pair of APIs in source code to allow Inspector to analyze or not analyze.

Please see below example code:

#include <stdio.h>

#include <memory.h>

#include <malloc.h>

 

#include <ittnotify.h>

int memory_leak()

{

char *s=malloc(256*sizeof(char));

printf("test leak\n");

return 1;

}

 

int overlap_copy()

{

int a[32];

 

memcpy(&a[0], &a[5], 8*sizeof(int));

 

printf("test overlap memory copy\n");

return 1;

}

 

void main()

{

     __itt_suppress_push(__itt_suppress_memory_errors); /* not allow Inspector to check */

     memory_leak();

     __itt_suppress_pop(); /* allow Inspector to check errors from next line */

     overlap_copy();

}  

 

# gcc -g test_memory.c -I/opt/intel/inspector_xe_2013/include /opt/intel/inspector_xe_2013/lib64/libittnotify.a -ldl -lpthread -o test_memory

 

Only 1 error was found.

# inspxe-cl -collect mi3 -- ./test_memory

Used suppression file(s):

test leak

test overlap memory copy

 

1 new problem(s) found

    1 Incorrect memcpy call problem(s) detected

 

 So, the developer can use APIs named __itt_suppress_push() and __itt_suppress_pop() to control Inspector's working.

Para obtener información más completa sobre las optimizaciones del compilador, consulte nuestro Aviso de optimización.