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:
memcpy(&a, &a, 8*sizeof(int));
printf("test overlap memory copy\n");
__itt_suppress_push(__itt_suppress_memory_errors); /* not allow Inspector to check */
__itt_suppress_pop(); /* allow Inspector to check errors from next line */
# 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 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.