Intel® Inspector XE 2013

Though it is likely that Intel Inspector XE 2013 can find any memory or threading errors present in the code paths exercised in applications when run at the highest levels of analysis, there is no guarantee that Intel Inspector XE 2013 will find all memory and threading errors in your program.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis and Pointer Checker operate differently. See "Setting Up Static Analysis" for more information on Static Analysis and the compiler documentation for more details on Pointer Checker..

No, they are injected into your program’s address space at runtime.

No, the current Intel® Inspector XE 2013 does not support process attach or detach. In order to find multithreaded bugs in your process, Intel® Inspector XE 2013 has to monitor memory initialization events (memory checking) or synchronization events (thread checking) from the start of the program.

Of course, you can always stop Intel® Inspector XE 2013 manually at any time after analysis starts.

Memory checking and thread checking perform dynamic analysis. In addition to the executable binaries and the input, the scheduling of the threads and the execution path also affect which issues the tools can find and report. Even when the executable binaries and the input are the same, the thread scheduling and the execution paths can be different from run to run.

The crash could be caused by a bug in your program or due to a bug in the tool. A latent bug in your program that did not appear when the program ran without the tool, could appear when running under the tool. The tool perturbs the program execution so the scheduling of the applications’ threads can be different with and without the tool. In addition, on the Windows* OS, the memory checking uses a fill pattern to mark uninitialized memory. If an application uses this uninitialized memory, a crash is possible. In this case, the last diagnostic produced by the memory checking would be an uninitialized read.

Since Intel® Inspector XE 2013 analysis tools execute in the program’s address space, a bug in the tool that can crash the tool will also crash the program.

If your program crashes, the product prints a message telling you if the crash is due to a bug in your code or a bug in the product. If the crash is due to a bug in your code, the message also points you to the crash location. If the crash is due to a bug in the product, the message will ask you to contact customer support.

Yes. Both memory checking and threading checking perform analysis on available cores or hardware threads utilized by the target parallel program. In general, the analysis overhead scales nicely and is similar to the scaling factor seen by the target application.

Of course, you will get better performance if you have a multi-core machine.

To analyze a plug-in module, you need to run the application that loads and executes the plug-in module under Intel® Inspector XE 2013. You can use the module include or exclude options to have Intel® Inspector XE 2013 only analyze the plug-in module.

No. Memory checking only detects errors that occur during the analysis run of your program.

Heap memory that has not been freed, and is not reachable, is reported as leaked at program termination. Reachability is determined by scanning global memory to find references to heap memory and then checking those memory regions, and so on, for further references.

In some circumstances, Intel® Inspector XE 2013 may report false positives or not report real problems. For example,
- Intel® Inspector XE 2013 may report false positives if the analyzed application uses custom memory management APIs and you do not annotate your source code to notify the analysis of your custom allocators.
- Intel® Inspector XE 2013 may report a false memory leak for an object that is located in global memory if its destructor does not execute until late in the shutdown process.
- Intel® Inspector XE 2013 uses some heuristics to eliminate false positives that may hide real issues.

First, use the Filters pane to focus on a particular module, source file or problem type. Then pick one problem from Problems pane and look at Code Locations pane. There you will see stacks for these code locations which can also help you to identify the problem. For problems related to a sequence of particular events (e.g. deadlocks) you might want to look at the Timeline pane which will show you distribution of this problem in time. Finally, try to double-click on interesting code locations to switch to the Sources window.

Every issue detected by the tool has at least one source stack associated with it. Some of these stacks may be more important than others, for example the two stacks of access associated with the threads that accessed the data in a data race are more important to resolving that problem than the stack of allocation (where the allocation occurred) of the object raced on. If two important stacks from two different issues of the same kind have the same “best” location, they are considered as observing the same location. Any two problems that share a location this way are considered to be part of the same problem set. Another way to think of this is that each problem set is a spanning tree of locations for one kind of issue.
The best location in a given stack is found using a heuristic that attempts to find the most basic stack location that is in the actual user code. Most of the time this works, but sometimes the best locations found may be in a user-written library or another low-level library that the user has source code for.

Yes, you can analyze a release optimized binary under Intel® Inspector XE 2013. However, there is no guarantee that Intel® Inspector XE 2013 will report the same issues as with a debug non-optimized binary and there is no guarantee that Intel® Inspector XE 2013 will show source lines or correct source lines. In addition, if the release build is not built with debug information, Intel® Inspector XE 2013 is unlikely to find as many problems as in a debug non-optimized build and in the case of memory checking, may report incorrect problems.

Yes, you can specify additional search directories on the Search tabs of the Intel Inspector XE 2013 Project Properties dialog box. For results created outside of the GUI, you need to create a project to configure these folders. If you are using the Microsoft Visual Studio* IDE, Intel® Inspector XE 2013 automatically retrieves additional search directories from your Visual Studio* project.

It depends on whether you are using the tool to enhance your total QA package or whether you are trying to use the tool to locate a specific issue that you are seeing.

• If you are looking for a specific problem, it makes sense to turn directly to the appropriate dynamic analysis tool for memory or thread checking. The dynamic tools allow you to easily focus on a smaller section of functionality and use an optimal dataset to find the problem that you are interested in as quickly as possible.
• If you are using the tool to enhance your full range of QA testing, we recommend starting with static analysis to remove as many issues as possible at compilation time and, then move to memory checking to find and fix memory issues and finally, to thread checking to find and fix threading issues which are usually hard to find and fix. If the application has race conditions, it’s possible that a fix for an incorrect access found by memory checking could be accomplished by resolving the race condition, which can only be detected by thread checking. It might also be the case that when running under memory checking, because it can alter scheduling and timing, a latent deadlock in the code might occur. Fixing the deadlock issue (which may be reported by thread checking), would enable a full run of the application under memory checking.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis operates differently. 

The Intel® Inspector XE 2013 interactive debugging feature allows you to use a standard debugger to investigate memory or threading problems found by Intel® Inspector XE 2013. It supports Microsoft* Visual Studio 2008 & Visual Studio 2010 debugger (Microsoft* Visual Studio 2012 support is coming) on Windows* OS and the Intel and GNU debuggers on Linux* OS.

It’s not that simple. Intel® Inspector XE 2013 does a binary runtime analysis of your application, which means there is analysis code executing part of the time, not just your application’s code. You can attach a debugger to this, but you would be looking at the analysis tool’s code much of the time and learn nothing about the problem the tool reported was in your code.

When debugging without memory or threading analysis, a code breakpoint will stop execution at the right location, but that location might be executed thousands of times before the conditions are right that resulted in the problem being reported. By combining debug with analysis, the tool does the work of determining when the problem conditions have occurred and stops at the right time as well as location.

On the Windows* OS when integrated with the Microsoft Visual Studio* IDE, the debug feature is accessible at two points: from the context-sensitive menu when viewing the list of problems in a result and when setting up a new analysis. On the Linux* OS when using the Intel® Inspector XE 2013 Standalone GUI, the debug feature is accessible in the same manner.

It is also available from the Linux* command line using the –appdebug or –debug-this options on the –collect action. Debugging during analysis is not available from the Intel® Inspector XE 2013 Standalone GUI or command line interface on the Windows* OS.

The most likely reason to use debug during an analysis is after you have examined the call stacks and code surrounding a particular memory or threading problem reported by Intel® Inspector XE 2013 and find you need more information to determine the cause, such as what the application’s variables hold at that point or what’s happening in other threads. Selecting Debug This Problem on the problem of interest returns you to that point of execution as quickly as possible since the analysis being done can be reduced in many cases.

Perhaps you want to check for errors in a particular section of an application that takes a long time to execute and the exclusion options do not provide the granularity level you’d like. You can reduce the time it takes to execute to the point within a module where you want error checking to begin by setting a code breakpoint and starting the run with the analysis off. When checking for threading errors, this technique is only efficient if the area chosen for analysis is quite small compared to the overall execution time when under analysis. Threading analysis optimization cannot be done during an analysis with debug enabled, leading to extremely slow execution. Running the complete analysis without debug may be faster than using the debug method to limit the area being analyzed. Checking for memory errors does not have this issue.

If you are looking for memory errors in an application for the first time and want the ability to debug in each problem as it is reported, then enabling the debugger with analysis from the start is what you want. As each memory problem is detected, execution will stop and you can look at the program state with the debugger or simply continue execution. In general, do not use this with threading analysis because the analysis optimizations cannot be done when debugging, as mentioned above, making execution too slow.

A leak occurs when memory or other resources were not released during execution of the application, hence they are not reported until after the application exits. Therefore, leaks would not result in breakpoints during execution.

For debugging to be effective, execution needs to halt at the point a problem occurred. In order to do that, the optimizations employed in threading analysis must be disabled. The result is extremely slow execution of thread checking when done in conjunction with debugging. To make debugging feasible, the level of analysis and location where it is done must be limited. When a problem is selected and Debug This Problem is used, those limitations are applied automatically. If the debug options are used when starting a threading analysis, care must be taken in which level of analysis is used and where analysis begins. Data race detection causes the worst slow down.

For debugging to be effective, execution needs to halt at the point a problem occurred. In order to do that, the optimizations employed in threading analysis must be disabled. The result is extremely slow execution of thread checking when done in conjunction with debugging. To make debugging feasible, the level of analysis and location where it is done must be limited. When a problem is selected and Debug This Problem is used, those limitations are applied automatically. If the debug options are used when starting a threading analysis, care must be taken in which level of analysis is used and where analysis begins. Data race detection causes the worst slow down.

You can reduce your data sets to make memory checking and thread checking run faster. As dynamic analysis tools, memory checking and thread checking detect errors on the code paths executed. As long as the execution paths are preserved, the size of data sets does not matter to analysis. Smaller data sets, however, reduce analysis workload and can boost analysis performance significantly.
Smaller data sets also reduce memory consumption by memory checking and thread checking tools, resulting in better performance. Furthermore, with thread checking, reduced memory consumption allows the tool to store more memory history information and to detect errors that can be missed when memory space is too tight and some memory history information has to be recycled in order for the analysis to continue.

To make thread checking run faster, you need to create your own analysis settings and have one or more of the following in your settings.

• Turn on only one type of checking at a time. For example, if you suspect you have a data race, turn on data race detection only but turn deadlock detection off, especially when there are lots of locks created in the program. If you suspect your program has a deadlock or lock hierarchy violation issue, try with only deadlock detection turned on.Turn off capturing the first access call stack using option -no-save-stack-on-first-access. Capturing the first access stack is expensive in terms of both time and space.
• Turn off capturing allocation call stacks using option -no-save-stack-on-allocation. Capturing the allocation call stack, especially in C++ programs with lots of objects allocated, is expensive in terms of both time and space.
• Reduce the number of levels of saved call stacks using the option -stack-depth. The deeper the call stack, the more memory space it takes and the more time to track the stack.
• Exclude modules you do not want to analyze with the option -exclude-module.
• Divide modules into several small sets. Analyze one set of modules at a time
  
  

Yes, you can specify the modules to be excluded in the GUI or command line for thread checking and memory checking.

However, this is not recommended for memory checking. Uninitialized memory or bad pointers can be passed into third-party libraries, and their use may not be detected if the third-party libraries were excluded. In cases like these, the problem is not in the third-party library.

Yes, you can create suppression rules for such problems. For subsequent analysis of that project, Intel® Inspector XE 2013 will still analyze those binaries, but problems in those modules will not appear in the result.
A new rule can be created from the GUI by clicking on the Suppress… item in the context menu on the Code Locations pane. You can select the Any… checkboxes to apply the same rule to a bigger set of problems.
Existing suppression rules are shown on the Intel® Inspector XE 2013 Project Properties > Suppressions tab.
As an alternative, you can exclude third-party modules from analysis completely. Excluding third-party modules from analysis also benefits performance. However, excluding third-party modules is not recommended for memory checking as described above.

Without additional annotations, Intel® Inspector XE 2013 may report false positives when analyzing applications containing custom memory management API or custom synchronization primitives.

Intel® Inspector XE 2013 provides a set of APIs to allow you to annotate your source code to notify the analysis of your synchronization and memory management APIs.