Find and debug errors in C, C++, and Fortran code early in your process.
Intel® Inspector doesn’t require any special recompiles for analysis. Use your normal debug or production build to catch and debug the errors. Check all code—including third-party libraries with unavailable sources—using the interface or command line (which allows for automated regression testing).
Debugger breakpoints simplify diagnosing difficult errors by breaking into the debugger just before the error occurs. When debugging outside of Intel Inspector, a breakpoint stops execution at the right location. However, that location might be executed thousands of times before the error occurs. By combining debug with analysis, Intel Inspector determines when a problem occurs and breaks into the debugger at the right time and location.
Figure 1: To debug a race condition or deadlock, select the error from the list, select Debug This Problem, and then rerun the code.
Figure 2: To manage overhead, select the analysis level.
In most cases, using Intel Inspector to find and debug memory and threading errors is quicker than manual debugging. However, your application typically runs slower while this tool analyzes it.
To address this, you have several options for managing overhead. First, choose a lighter analysis for your daily builds and then a more complete analysis as you start to freeze code (see Fig. 2).
Another option is to speed up analysis by limiting its scope. You can enable analysis only during the execution of the suspected problem and skip analyzing irrelevant sections of code. Used carefully, this can be beneficial in situations where long run times are required to reach the error.
You can also speed up analysis using an API to mark memory you don’t want to be analyzed (for example, it contains a synchronization data structure).
Note You can work on something else while Intel Inspector is analyzing your application.
Threading errors are usually nondeterministic and difficult to reproduce. Intel Inspector helps detect and locate threading errors, such as data race conditions (heap and stack races), deadlocks, lock hierarchy violations, and cross-thread stack access errors.
Figure 3. Correct execution depends upon executing the instructions in the correct order. But without a lock on the shared variable, there is no guarantee the threads are running in the proper sequence.
Figure 4. Reveal the source locations of memory errors and access a call stack to trace the path to the error.
Figure 5. Memory growth analysis
This tool graphically shows memory growth as the application is running (see Fig. 5). It then lets you locate the call stack and code that's responsible for the memory growth.
This analysis (see Fig. 6) enables a faster diagnosis of the increase in memory use. Get an incremental heap growth report of allocations that are not matched with deallocations, and an incremental report of leaks since the last baseline.
Figure 6. Memory heap growth analysis