Intel® Inspector 2017

Memory and Thread Debugger

  • Save money: Find and root cause errors early―before you release
  • Save time: Quickly debug intermittent races and deadlocks
  • Save effort: No special builds―just use your normal build

Detects Both Memory and Threading Errors

Memory errors like leaks, corruption, and illegal accesses can be very hard to find without a tool. Threading errors like races and deadlocks can be even harder because they are normally non-deterministic and difficult to reproduce. Intel® Inspector finds errors and makes them deterministic and debuggable. Check out the complete list of threading and memory errors:

Dynamic Instrumentation: Simple, Reliable, Accurate

Unlike other memory and threading analysis tools, Intel Inspector never requires any special recompiles for analysis. Just use your normal debug or production build. (Include symbols so we can map to the source.) This not only makes your workflow faster and easier, it increases reliability and accuracy. Competitive static, compilation-based instrumentation techniques struggle with dynamically generated or linked code. Intel Inspector inspects all code including third-party libraries where the source is not available.

Check and Debug C, C++ and Fortran Applications

Or any mix. Got legacy code in Fortran*? Using libraries without the source? No problem, it all works. Dynamic instrumentation enables inspection of all code including third-party libraries where the source is not available.

Choose Your Level: Go Fast or Be Thorough

The first level of analysis has very little overhead. Use it during development because it is fast. The second level (shown) takes more time and detects more issues. It is often used before checking in a new feature. The third level is great for regression testing and finding bugs.

Choose Your Level

Debugger Breakpoints Simplify Diagnosis

Debugger breakpoints make it easier to diagnose difficult errors by breaking into the debugger just before the error occurs. Examine variables and look at other threads to diagnose the problem. Visual Studio*, GDB*, and IDB* debuggers are supported. Just select the error and choose “Debug This Problem” from the pop-up menu.

Debugger Breakpoints Simplify Diagnosis

Incrementally Diagnose Memory Growth

Intel Inspector graphically shows memory growth as the application is running. It then lets the developer specify a cause for the memory growth and provides call stack and code snippet information to help eliminate it.

Memory Used by Analysis Tool and Target Application

Analyze Heap Growth Incremental Leak Report

Puzzled about what is causing your memory use to grow and grow as your app continues to run? Heap growth analysis helps you diagnose the cause. Get an incremental heap growth report of allocations not deallocated since the last baseline. Now you can also get an incremental report of leaks since the last baseline.

Analyze Heap Growth

Pause/Resume Speeds Up Analysis

Speed up analysis by limiting its scope. Turn on analysis only during the execution of the suspected problem. Instrumentation overhead is reduced to speed through long, irrelevant sections of code. Used carefully, this can be very powerful in situations where long run times are required to reach the error.

Speed Analysis with Pause/Resume

Suppress False Errors, Share with the Team

False errors are easily added to a suppression list so you don’t need to investigate them next time. Multiple lists are supported and can be shared with other project members. Create your own private suppressions to block errors that are not in your code. Suppressing an entire module can also reduce collection time.

Precise Suppressions Remove False Errors Safely

Team Collaboration

Each error reported contains state information (New, Confirmed, Fixed, Not Fixed, Regression, Not a Problem, Deferred) to help you sort and prioritize errors.

Error Reports Contain State Information

Filters Manage the Error List

Just want to see the errors from your source file? Click and only those errors are shown. Working through the new errors and only want to see the highest severity? Just click. Filters are available for many categories including severity, problem type, state, module, etc. They weed out the noise and let you focus on what is most important.

Inspect Software for Intel® Xeon Phi™ Processors and Coprocessors

Intel Inspector now runs natively on Intel® Xeon Phi™ self-boot processors. It can also be used to analyze software for Intel® Xeon Phi™ coprocessor product, even though the analysis does not run natively on an Intel Xeon Phi coprocessor. Inspecting your app with Intel Inspector while running it on a multicore processor will detect memory and threading errors that will occur when running on Intel Xeon Phi coprocessors.

Limit Analysis Range

Eliminate false errors and speed up analysis by using an API to mark memory that should not be analyzed (e.g., it contains a synchronization data structure).

Fewer False Positives, Better Error Messages

Intel Inspector understands the semantics of the Intel® Threading Building Blocks (Intel® TBB), Intel® OpenMP, and Intel® Cilk™ Plus parallel programming models. This saves time.

  • It reports fewer false positives than competitive products.
  • Errors are described using familiar terms from the source, not with cryptic internal runtime labels.

Multi-OS (Windows* and Linux*): Same User Interface

Are you developing for both Windows* and Linux*? Wouldn’t it be easier to use the same analysis tools for both? Intel Inspector has the same user interface on both Windows and Linux. On Windows, it can be used standalone or integrated with Microsoft Visual Studio*.

Analyze MPI Applications for Memory and Threading Errors

Intel Inspector can find both memory and threading errors on MPI applications. Performing an initial analysis on a single shared memory system will identify many errors. And additional analysis can also be run on a cluster. Results are sorted by rank.

Pointer Checker: Find Difficult-to-Diagnose, Out-of-Bounds Accesses

Pointer Checker is a compiler-based diagnostic that traps memory accesses beyond allocated addresses. Find dangling pointers, buffer overflows, etc. Speed up diagnosis by breaking into the debugger when the exception occurs. Just compile using the Intel compiler with Pointer Checker enabled (/Qcheck-pointers on Windows or –check-pointers on Linux), and then run your code. It identifies and reports out-of-bounds memory accesses.

Windows Pointer Checker:

Linux Pointer Checker: