Intel® Inspector XE 2013

Memory and thread debugger.

  • Find memory leaks and memory allocation errors quickly.
  • Locate difficult to find threading errors like data races and deadlocks.
  • Detect out of bounds accesses and dangling pointers.** (When purchased as a part of one of the Intel® Parallel Studio XE family of suites.).**

From $899
Buy Now

Or Download a Free 30-Day Evaluation Version

Deliver More Reliable Applications

Intel® Inspector XE 2013 is an easy to use dynamic memory and threading error detector and debugger for Windows* and Linux*.  Enhance productivity, cut cost and speed time-to-market.

Find errors that traditional regression testing and static analysis miss. 
Dynamic analysis reveals subtle defects or vulnerabilities whose cause is too complex to be discovered by static analysis.  Unlike static analysis, debugger integration lets you diagnose the problem and find the root cause.  Intel Inspector XE finds latent errors on the executed code path plus intermittent and non-deterministic errors, even if the error-causing timing scenario does not happen.


Intel Inspector XE takes you to the source locations of threading and memory errors and provides a call stack to help you determine how you got there.

Memory Errors

Threading Errors

  • Memory leaks
  • Memory corruption
  • Allocation / de-allocation API mismatches
  • Inconsistent memory API usage
  • Illegal memory access
  • Uninitialized memory read
  • Data races
    • Heap races
    • Stack races
  • Deadlocks

List of errors: Windows* | Linux*

Find crucial threading and memory errors early in the development cycle. The earlier you find an error, the lower the cost to fix it. Intel® Inspector XE 2013 makes it easy to find and diagnose errors early.

C, C++, C# and Fortran.  Or any mix. 

Is your GUI in C# with performance sensitive code in C++?  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.

Fits your workflow.

No special compilers or builds are required, just use your normal debug or production build.  Inspect the same code you are debugging and shipping.   Use the graphical user interface or automate regression testing with the command line.  The user interface can be used standalone on both Windows* and Linux* or integrated with Microsoft Visual Studio*.

Bonus:  Get static analysis and pointer checker features when you buy a studio.

The Intel® compiler is not required to use Intel Inspector XE, but you do get additional Intel compiler-based features when you purchase one of the studio products that include both the compiler and Intel Inspector XE.  Static analysis finds security issues.  Pointer Checker is a compiler-based diagnostic that traps memory accesses beyond allocated addresses.

New! Debugger integration, heap growth analysis, incremental leak analysis, OpenMP 4.0 support, precise suppressions and more


Quotes

“Intel® Inspector XE is quite fast and intuitive compared to products we have used in the past. We can now run our entire batch of test cases (~750) which was not feasible previously.  Intel® Inspector XE easily completed tests that failed due to lack of virtual memory on another product.”
Gerald Mattauch
Senior Software Developer
Siemens AG, Healthcare Sector

“We struggled for a week with a crash situation, the corruption was identified but the source was really hard to find. Then we ran Intel® Inspector XE and immediately found the array out of bounds that occurred long before the actual crash.  We could have saved a week!”
Mikael Le Guerroué,
Senior Codec Architecture Engineer,
Envivio

Finds Memory Errors

  • Memory leaks
  • Memory corruption
  • Allocation / de-allocation API mismatches
  • Inconsistent memory API usage
  • Illegal memory access
  • Uninitialized memory read

Finds Threading Errors

  • Data races
    • Heap races
    • Stack races
  • Deadlocks

List of errors: Windows* | Linux*

Fits your workflow.

No special builds are required, just use your normal debug or production build. Inspect the same code you are debugging and shipping. Use the friendly graphical user interface or automate regression testing with the command line. The user interface can be used standalone on both Windows* and Linux*

C, C++, C# and Fortran.

Or any mix. Is your GUI in C# with performance sensitive code in C++? 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.

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.

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. New! Now you can also get an incremental report of leaks since the last baseline.

 

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.

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.

Suppressions are now easier to edit, more precise and shareable. Eliminate the false error(s) without suppressing potential real errors.

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.

State information from multiple developers can be merged and shared. Users can optionally comment on errors to explain why a certain state was set.

Filters Manage the Error List

Just want to see the errors from your source file? Just 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: 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™ products 

Intel® Inspector XE 2013 can be used to analyze software for Intel® Xeon Phi™ coprocessor products even though the analysis does not run on an Intel® Xeon Phi™ coprocessor. Inspecting your app with Intel Inspector XE running your app on a multicore processor will detect memory errors 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)

Dynamic Instrumentation:
Simple, Reliable, Accurate

Unlike other memory and threading analysis tools, Intel Inspector XE 2013 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 XE 2013 inspects all code including third party libraries where the source is not available.

Fewer False Positives, Better Error Messages

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

1) It reports fewer false positives than competitive products.

2) Errors are described using familiar terms from the source, not with cryptic internal runtime labels.

Multi-OS (Windows* & 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 OSs? Intel Inspector XE 2013 has the same user interface on both Windows* and Linux*. On Windows* it can be used stand alone or integrated with Microsoft Visual Studio*.

Analyze MPI Applications for Memory and Threading Errors

Intel Inspector XE 2013 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.

Technical Specifications

For additional details, please see the Intel® Inspector XE documentation and release notes.

“Intel® Inspector XE is quite fast and intuitive compared to products we have used in the past. We can now run our entire batch of test cases (~750) which was not feasible previously. Intel® Inspector XE easily completed tests that failed due to lack of virtual memory on another product.”
Gerald Mattauch
Senior Software Developer
Siemens AG, Healthcare Sector

“We struggled for a week with a crash situation, the corruption was identified but the source was really hard to find.  Then we ran Intel® Inspector XE and immediately found the array out of bounds that occurred long before the actual crash. We could have saved a week!”
Mikael Le Guerroué,
Senior Codec Architecture Engineer,
Envivio

“The video processing and encoding libraries we develop need to be error free. Intel® Inspector XE has dramatically sped up our ability to find/fix memory problems and track down difficult to isolate threading errors before our packages are released to the field.”
Peter von Kaenel
Director, Software Development
Harmonic Inc.

Static Analysis** finds over 250 common security violations

When conducting static code analysis, errors are listed with a short explanation and initially sorted by weight. State is set to "new" the first time an error is detected. You can change this to "confirmed," "fixed," or "not a problem" as you investigate the errors.  Examples of errors

**Bonus:  Get static analysis when you buy a studio. The Intel® compiler is not required to use Intel Inspector XE, but you do get additional Intel compiler-based features when you purchase one of the studio products that include both the compiler and Intel Inspector XE.  Static analysis does use the front-end of the Intel compiler, but this does not mean you need to switch compilers.  You can continue to use your existing compiler for code generation.

.

Quickly locate the error in your source code

 

Double click the error to see it highlighted in the source with its traceback. Errors with multiple source locations show both the focus code location and the related code location.

Easy Setup in Visual Studio

Set up is automated with a simple menu/dialog driven approach that automatically configures your solution for static analysis. From the menus choose: “Build > Build Solution for Intel Static Analysis”

Setup for Linux* or Windows* command line builds
Please see the eval guide or the documentation.

 

Focus on the most important errors first

Extensive filtering lets you see all the errors, or show only the errors in one source file. Just click to add filters for conditions like state, severity, type, category, suppressed and more. Focus on just your code, or just the new errors in the latest build, or just the confirmed errors you plan to fix. You have full control.

Explains the problem and suggests a fix

Choose "Explain Problem" from the pop-up menu to get a detailed explanation of a problem and how to fix it.

Example Coding Errors:

  • Memory and resource leaks
  • Incorrect use of OpenMP* directives
  • Incorrect use of Intel® Cilk™ Plus language features
  • Pointer and array errors
  • Error-prone C++ and Fortran language usage
More examples of coding and security errors.

 

Example Security Errors:

  • Buffer overflows and boundary violations
  • Use of uninitialized variables and objects
  • Incorrect usage of pointers and dynamically allocated memory
  • Dangerous use of unchecked input
  • Arithmetic overflow and divide by zero
  • Misuse of string, memory, and formatting library routines

Microsoft Source Annotation Language*

Dynamic Libraries

Static analysis provides the best results when it has all the source code. On Linux* dynamic libraries are supported. On Windows* Microsoft Source Annotation Language* (SAL) gives static analysis the data it needs even if the source is unavailable.

Technical Specifications

For additional details on static analysis, please see the compiler documentation and release notes.

“Intel’s static analysis allows us to close issues before the product ships. It locates “hard to find” errors (e.g., potential null pointers on conditional paths) that are unfortunately quite typical.”
Mikael Le Guerroué,
Senior Codec Architecture Engineer,
Envivio

“I inherited 20 - 30,000 lines of mostly uncommented Fortran 77 code that contained a bug that showed up ‘down-the-road’. After more than a week of pure frustration, I gave up on finding it. Later, I tried Intel’s Static Analysis and found the bug, along with at least 10 other error prone portions of code. Time saved? No idea, maybe I’d still be fighting it.”
Dr. Artur Guzik,
Senior Engineer,
R&D, Neubrex Co., Ltd.

Pointer Checker**

  • Detect and prevent buffer overflows
  • Reduce the risk of common malware exploits
  • Root cause programming errors

**Bonus:  Get pointer checker when you buy a studio. The Intel® compiler is not required to use Intel Inspector XE, but you do get additional Intel compiler-based features when you purchase one of the studio products that include both the compiler and Intel Inspector XE.

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.

Windows*:

Easy to use – just add a compiler switch

When you compile with Pointer Checker enabled (/Qchecked-pointers on Windows or –checked-pointers on Linux), and then run your code, it identifies and reports out-of-bounds memory accesses.  There is overhead associated with this diagnostic so after you fix the identified problems, you can recompile a release-version without Pointer Checker enabled to remove the overhead of this feature.

Linux*:

Technical Specifications

For additional details on pointer checker, please see the compiler documentation and release notes.

What’s New in 2013 SP1?

We continuously release new features in regular updates available to all customers with a current service agreement (one year included with purchase).  Just download, install and get all the latest stuff.   Here is a partial list of new features released since our first release of Intel Inspector XE 2013:  (For more details, see our Release Notes.)

Easier Migration From Other Tools

  • Import suppression lists from Purify* and Valgrind* on Linux*

Fewer False Errors and Easier Suppression Management

  • Precise suppressions specify single or multiple stack locations
  • User editable suppression files (or use the GUI)
  • Fortran – reduced false positives due to allocation

Leak Reports No Waiting!

  • Set a baseline for incremental analysis with GUI or API
  • Report incremental leaks and heap growth since the baseline
  • No waiting until the end of the analysis run 

New OS, Threading Model & Processor Support

  • Windows* 8 desktop
  • Visual Studio* 2012 & 2013
  • Latest Linux* distributions
  • OpenMP 4.0
  • Haswell – Windows* & Linux*

What’s New in 2013?

Here are highlights of improvements made to the 2011 product:

Easier To Use

  • Debugger Breakpoints Simplify Diagnosis
  • Team collaboration for analysis state information (new, fixed, not fixed, etc.)

Faster Results

  • Pause / Resume speeds up analysis by limiting its scope
  • Limit analysis range speeds up analysis by turning it off when it is not needed

More Analysis Capability

  • Heap Growth Analysis
  • Analysis of MPI applications
  • Pointer Checker

Videos to help you get started.

Register for future Webinars


Previously recorded Webinars:

  • Precision Memory Leak Detection Using the New On-Demand Leak Detection in Intel® Inspector XE
  • Locate and debug troublesome memory and threading errors with Intel® Inspector XE
  • Featured Speakers
  • Intel® Software Correctness – Dynamic & Static Analysis
  • Analysis of hybrid applications with the Intel Cluster Studio XE 2012
  • Note: Video portion will load in about 1 minute, audio will start immediately

    Download slides

  • Using Intel® Inspector XE with Fortran Applications
  • Note: Video portion will load in about 1 minute, audio will start immediately

    Download slides

More Tech Articles

Useful Links for Intel® Inspector XE 2013 and Intel® Inspector for Systems 2013
By Holly Wilper (Intel)Posted 04/16/20130
    Here are some helpful links:           Important Knowledge Base Articles for Intel® Inspector XE 2013   Detecting memory growth Measuring cyclomatic complexity Taking advantage of interactive debugging   Handling suppressions Using collection control APIs   Controlling analy...
Intel® Inspector XE 2013: Controlling Analysis Cost
By Holly Wilper (Intel)Posted 02/26/20130
Intel® Inspector XE 2013: Controlling Analysis Cost Find memory and threading errors faster Introduction   Intel® Inspector XE 2013 detects challenging threading and memory errors and provides guidance to help ensure application reliability. When you run an analysis, the Intel Inspector XE execut...
How to use Intel® Inspector for Systems
By kevin-oleary (Intel)Posted 02/06/20130
Background Intel® System Studio is the new embedded software tool suite and includes Intel® Inspector for Systems. This article will explain the steps you need to follow to run Inspector for Systems on an embedded platform. Overview We will use Yocto Project* version 1.2 as an example. This pl...
How to Detect and Repair Correctness Issues in Code to Run on the Intel® Xeon Phi™ Coprocessor Architecture with Intel® Inspector XE
By Holly Wilper (Intel)Posted 01/30/20130
How to Detect and Repair Correctness Issues in Code to Run on the Intel® Xeon Phi™ Coprocessor Architecture with Intel® Inspector XE   Intel® Xeon Phi™ coprocessors combine advanced power performance with the benefits of standard CPU programming models.  Developing and tuning for Intel® Xeon Ph...

Pages

Subscribe to

Supplemental Documentation

Intel Software Tools Webinar Series Archive
By Abby Wang (Intel)Posted 02/18/20140
This free webinar series presented tools, tips, and techniques that will help sharpen your development skills on Intel processors/coprocessors including Intel® Xeon® processor and Intel® Xeon Phi™ coprocessor. Intel technical experts as well as open source innovators discuss topics ranging from c...
Precision Memory Leak Detection Using the New On-Demand Leak Detection in Intel® Inspector XE
By christina-king-wojcik (Intel)Posted 12/06/20130
Intel® Inspector XE now gives you the ability to set and reset memory baselines and ask for memory leak information from your program whenever you want it. You will learn how to skip analysis of sections of the code you are not interested in, how to choose whether memory growth or on-demand leak ...
Finding Memory Leaks and Memory Growth With Intel® Inspector XE
By Holly Wilper (Intel)Posted 11/01/20130
There are several ways that you can use the Intel® Inspector XE to get insight into how your applications use memory. This guide helps you better understand the different types of information that the Intel Inspector XE can give you about your application’s memory usage and how you can use that ...
What's new? Update 7 - Intel® Inspector XE 2013
By Holly Wilper (Intel)Posted 08/06/20130
Intel® Inspector XE 2013 The Intel® Inspector XE 2013 helps developers identify and resolve memory and threading correctness issues in their C, C++ and Fortran programs. New for Update 7 A new on-demand memory leak detection feature to detect if a block of memory is allocated, but not dealloc...

Pages

Subscribe to

You can reply to any of the forum topics below by clicking on the title. Please do not include private information such as your email address or product serial number in your posts. If you need to share private information with an Intel employee, they can start a private thread for you.

New topic    Search within this forum     Subscribe to this forum


Intel(r) Inspector XE 2013 Update 9 is now available
By Holly Wilper (Intel)0
New for Update 9: Performance and memory consumption improvements during threading error analysis, on average a 3X performance improvement and many applications that ran out of memory can now be analyzed - The Intel Inspector still finds most data race and cross-thread stack access problems. If you discover you are missing problems, use the new Use maximum resources configuration setting to return to previous behavior. New suppression summary statistics when analysis is complete - Show how many suppression files and rules the Intel Inspector applied and how many problem instances it suppressed. New memory consumption graph during analysis - Shows how much memory the target application plus the Intel Inspector consume during analysis. Improved on-demand memory leak detection and memory growth measurement - Gathering memory leak information while an application is running is useful if: An application does not terminate (such as a server process). You want memory leak information, but ...
Internal Error running Memory Analysis
By Frankie F.1
Hello, Our test case stops with this message. Should I send you result directory for diagnosis? [CmExecIntelInspector] Error: Internal error. Please contact Intel customer support team. [CmExecIntelInspector] Error: Internal error. Please contact Intel customer support team. [CmExecIntelInspector] Error: Internal error. Please contact Intel customer support team. [CmExecIntelInspector] Error: Internal error. Please contact Intel customer support team. [CmExecIntelInspector] Error: Internal error. Please contact Intel customer support team. [CmExecIntelInspector] Warning: Encountered an issue while loading result [/mnt/sda7/home/omneon/workspace/RmpFramework_DynamicAnalysis-1.0.x.0_mc_sdk_src-matrix/label/TST_LIN/RmpFramework_DynamicAnalysis/RMP/intelinspector_results/mi2_009]. Run terminated abnormally. Some data may be lost. [CmExecIntelInspector] [CmExecIntelInspector] 38 new problem(s) found [CmExecIntelInspector] 23 Invalid partial memory access problem(s) detected [Cm...
FYI: linux process failure from vm.max_map_count overrun
By vanswaaij0
  If a process (running with or without Inspector XE) fails with a insufficient memory error while the machine seems to have plenty left, a vm.max_map_count overrun could be the problem. Here's how to find out what the per process limit is: sysctl vm.max_map_count > vm.max_map_count = 65530 And how to estimate how many mappings your process us using cat /proc/<process id>/maps | wc -l I've seen the problem occur for a process (Autodesk's maya) that uses the mmap system call directly for many smallish allocations.  
erroneous memory leak detection from Fortran 90 MPI operations
By burnesrr2
I have been using Inspector XE to look for memory leaks and it is reporting a memory leak where I would not expect one from an MPI operation. The unusual behavior is that if the size of the transfer is below a certain array size no memory leaks are reported, but if the array size is larger than this threshold then a memory leak is reported. I have attached a simple Fortran 90 program that demonstrates the behavior along with the makefile necessary to compile it. The command to execute the program that I have been using is: mpirun -np 2 inspxe-cl -r InspectorResults -collect mi3 <absolute path to executable>/test If I set arraysize=10000 no memory leak is detected, but if I set the variable arraysize=20000 a memory leak is reported. Please see the screen shots included. both the send buffer and the receive buffer are reported as having memory leaks. The versions of the Fortran compiler and Inspector XE I am using are: [rick@RainierLinux testmpi]$ ifort -V Intel(R) Fortran Inte...
valgrind suppresion file conversion failure
By vanswaaij1
Hi, I'm trying to convert the attached valgrind suppression file but get this message: /opt/intel/inspector_xe_2013/bin64/inspxe-cl -convert-suppression-file -from "./valgrind_maya.txt" -to "./inspxe_maya.sup" Error: Unable to convert old format or third-party suppression file <snip>./valgrind_maya.txt to new suppression file <snip>./inspxe_maya.sup. Failed to load suppression file. The suppression file works with valgrind-3.9.0 Thanks.
will executable-of-interest survive multiple forks?
By vanswaaij2
Hi, we have a binary with a complicated launch sequence that consists of a cascade of scripts. Will the executable-of-interest option survive this cascade or does it only look at the child processes of the top most script? Thanks.
Firefox: Windows help viewer pane is blank when viewing CHM file
By Bob L. HUD (Intel)0
Hello Forum:  We have noticed that the Intel® Parallel Studio XE documentation may not function correctly when accessed with the Firefox* browser. The exhibited behavior is that the right-hand pane (reading pane) in the help viewer is blank, and this problem may well extend to other documentation collections as well.  Any CHM file downloaded from the Firefox* browser could exhibit this problem. The root cause seems to be that Firefox by default sand-boxes files downloaded from the Internet.  This appears to place a security restriction on the file that does not exist on files downloaded in other browsers (we tested Chrome and Internet Explorer).  The confusing part is that the file is really local and not from the Internet at all, but it seems Firefox doesn't know this, or perhaps doesn't care, and defaults to the safer road less traveled. There is a way to change this in the system registry, but the recommended solution is to turn this feature off in Firefox itself.  The process ...
Inspector XE 2013 Update 9 SIGSEGV on startup
By vasci_5
I can't run Inspector XE 2013 Update 9 GUI. I am running on CentOS 6. Othe lintel tools such as ampl-xe-gui run fine.Any ideas?   Program received signal SIGSEGV, Segmentation fault. 0x00002aaaac120a45 in cfgmgr2::ConfigDescriptorRegistry::ConfigDescriptorRegistry(cfgmgr2::config_type_t, char const*) ()    from /opt/intel/inspector_xe_2013/bin64/../lib64/libinspxe_cfgmgr_2.19.so (gdb) bt #0  0x00002aaaac120a45 in cfgmgr2::ConfigDescriptorRegistry::ConfigDescriptorRegistry(cfgmgr2::config_type_t, char const*) ()    from /opt/intel/inspector_xe_2013/bin64/../lib64/libinspxe_cfgmgr_2.19.so #1  0x00002aaaac120806 in cfgmgr2::IConfigDescriptorRegistry::create(cfgmgr2::config_type_t, gen_helpers2::sptr_t<cfgmgr2::IContextValueMap const>)     () from /opt/intel/inspector_xe_2013/bin64/../lib64/libinspxe_cfgmgr_2.19.so #2  0x00002aaab31b3e94 in client_2_7_41::xe::loader::cmdmgr_t::get_all_run_commands() const ()    from /opt/intel/inspector_xe_2013/lib64/libinspxe_client_load...

Pages

Subscribe to Forums
  • Will Intel Inspector XE 2013 find all memory and threading errors in my program?
  • 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.

  • Do I have to recompile and rebuild my programs to use Intel® Inspector XE 2013?
  • 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..

  • Does Intel® Inspector XE 2013 thread checking analysis and memory checking analysis run in a separate process?
  • No, they are injected into your program’s address space at runtime.

  • Can Intel® Inspector XE 2013 attach to or detach from my running process?
  • 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.

  • Why does Intel® Inspector XE 2013 memory checking or thread checking report different errors in two different runs with the same executable binaries and the same input?
  • 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.

  • My program works fine without Intel® Inspector XE 2013, but it crashes when running under Intel® Inspector XE 2013. Is there a bug in the product causing my program to crash?
  • 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.

  • How do I know my program was crashed by a bug in my program or a bug in your product?
  • 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.

  • Will thread checking find logical errors such as atomicity violations in my program, for example, 2 memory accesses that should be in the same critical section are in 2 different critical sections?
  • No, thread checking in current product releases does not detect logical errors such as atomicity violations.
  • For parallel programs, does threading (or memory) analysis run in parallel? In other words, does analysis make use of available multi-core hardware?
  • 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.

  • Do I have to run thread checking on a multi-core machine? I use a single processor and single-core machine for my development. Can I still use thread checking to find bugs in my code?
  • Intel® Inspector XE 2013 is capable of detecting threading errors even on single-core machines. You don’t have to run thread checking on a multi-core machine as long as your program uses multiple threads. If your program creates threads explicitly using Windows* or POSIX* threading APIs, you don’t have issues with creating multiple threads on a single-processor and single-core machine.If your program uses Intel® Threading Building Blocks (Intel® TBB), OpenMP* pragmas, Intel® Cilk™ Plus, or another task or threading model that normally creates threads based on the number of available cores on the machine, you need to force the underlying threading model to create multiple threads.

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

  • I am developing a plug-in module. How can I use Intel® Inspector XE 2013 to analyze it?
  • 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.

  • Is memory checking capable of finding potential errors in my program?
  • No. Memory checking only detects errors that occur during the analysis run of your program.

  • Are all leaks reported actually problems? My program allocates heap memory and because the allocated memory is reclaimed by the operating system when the program terminates, why does Intel® Inspector XE 2013 still report leaks?
  • 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.

  • I got dozens of problems, where do I start?
  • 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.

  • How is a “problem set” formed exactly?
  • 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.

  • Can Intel® Inspector XE 2013 analyze a release optimized binary?
  • 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.

  • I have source files and symbol files somewhere but Intel® Inspector XE 2013 cannot find them. Is there any way I can tell Intel® Inspector XE 2013 where to find source and symbol files?
  • 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.

  • I have memory checking, thread checking and static analysis installed on my machine. In which order do you recommend using the tools during the development process so I make the best use of the product?
  • 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.
  • Do I have to recompile and rebuild my programs to use Intel® Inspector XE 2013?
  • 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. 

  • What is the interactive debugging feature?
  • 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.

  • Can’t we can simply start an analysis and attach a debugger to it?
  • 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.

  • Why would I want to do debug simultaneously with an analysis session when the Intel® Inspector XE 2013 problem report gives me the code location (I can run the application under the debugger the way I always have and set a code breakpoint.)?
  • 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.

  • Where do I find the debug feature?
  • 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.

  • When would I want to debug during an analysis?
  • 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.

  • Why can’t I use Debug This Problem on memory or resource leaks (or, Why didn’t a debug analysis run stop at the memory or resource leak problems that were reported)?
  • 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.

  • Why is execution so slow when doing threading analysis with a debugger (or, I waited an hour and never reached a breakpoint when it normally completes the entire analysis in that time)?
  • 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.

  • Why is execution so slow when doing threading analysis with a debugger (or, I waited an hour and never reached a breakpoint when it normally completes the entire analysis in that time)?
  • 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.

  • Intel® Inspector XE 2013 slows down my application significantly under memory checking and thread checking analysis. How can I make it faster?
  • 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.

  • I am already using the smallest data sets, but thread checking is still slow with my application. How can I make it run faster?
  • 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

  • I am using third-party code in my development. Can Intel® Inspector XE 2013 exclude the third-party binaries and focus on my code?
  • 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.

  • I don’t mind analyzing third-party modules but I don’t want to see problems in them. Can you hide problems in third-party binaries?
  • 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.

  • I have my own synchronization or memory management APIs. Can I still use Intel® Inspector XE 2013?
  • 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.

  • Will Intel Inspector XE 2013 find all memory and threading errors in my program?
  • 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.

  • Do I have to recompile and rebuild my programs to use Intel® Inspector XE 2013?
  • 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..

  • Does Intel® Inspector XE 2013 thread checking analysis and memory checking analysis run in a separate process?
  • No, they are injected into your program’s address space at runtime.

  • Can Intel® Inspector XE 2013 attach to or detach from my running process?
  • 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.

  • Why does Intel® Inspector XE 2013 memory checking or thread checking report different errors in two different runs with the same executable binaries and the same input?
  • 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.

  • My program works fine without Intel® Inspector XE 2013, but it crashes when running under Intel® Inspector XE 2013. Is there a bug in the product causing my program to crash?
  • 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.

  • How do I know my program was crashed by a bug in my program or a bug in your product?
  • 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.

  • Will thread checking find logical errors such as atomicity violations in my program, for example, 2 memory accesses that should be in the same critical section are in 2 different critical sections?
  • No, thread checking in current product releases does not detect logical errors such as atomicity violations.
  • For parallel programs, does threading (or memory) analysis run in parallel? In other words, does analysis make use of available multi-core hardware?
  • 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.

  • Do I have to run thread checking on a multi-core machine? I use a single processor and single-core machine for my development. Can I still use thread checking to find bugs in my code?
  • Intel® Inspector XE 2013 is capable of detecting threading errors even on single-core machines. You don’t have to run thread checking on a multi-core machine as long as your program uses multiple threads. If your program creates threads explicitly using Windows* or POSIX* threading APIs, you don’t have issues with creating multiple threads on a single-processor and single-core machine.If your program uses Intel® Threading Building Blocks (Intel® TBB), OpenMP* pragmas, Intel® Cilk™ Plus, or another task or threading model that normally creates threads based on the number of available cores on the machine, you need to force the underlying threading model to create multiple threads.

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

  • I am developing a plug-in module. How can I use Intel® Inspector XE 2013 to analyze it?
  • 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.

  • Is memory checking capable of finding potential errors in my program?
  • No. Memory checking only detects errors that occur during the analysis run of your program.

  • Are all leaks reported actually problems? My program allocates heap memory and because the allocated memory is reclaimed by the operating system when the program terminates, why does Intel® Inspector XE 2013 still report leaks?
  • 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.

  • I got dozens of problems, where do I start?
  • 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.

  • How is a “problem set” formed exactly?
  • 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.

  • Can Intel® Inspector XE 2013 analyze a release optimized binary?
  • 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.

  • I have source files and symbol files somewhere but Intel® Inspector XE 2013 cannot find them. Is there any way I can tell Intel® Inspector XE 2013 where to find source and symbol files?
  • 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.

  • I have memory checking, thread checking and static analysis installed on my machine. In which order do you recommend using the tools during the development process so I make the best use of the product?
  • 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.
  • Do I have to recompile and rebuild my programs to use Intel® Inspector XE 2013?
  • 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. 

  • What is the interactive debugging feature?
  • 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.

  • Can’t we can simply start an analysis and attach a debugger to it?
  • 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.

  • Why would I want to do debug simultaneously with an analysis session when the Intel® Inspector XE 2013 problem report gives me the code location (I can run the application under the debugger the way I always have and set a code breakpoint.)?
  • 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.

  • Where do I find the debug feature?
  • 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.

  • When would I want to debug during an analysis?
  • 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.

  • Why can’t I use Debug This Problem on memory or resource leaks (or, Why didn’t a debug analysis run stop at the memory or resource leak problems that were reported)?
  • 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.

  • Why is execution so slow when doing threading analysis with a debugger (or, I waited an hour and never reached a breakpoint when it normally completes the entire analysis in that time)?
  • 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.

  • Why is execution so slow when doing threading analysis with a debugger (or, I waited an hour and never reached a breakpoint when it normally completes the entire analysis in that time)?
  • 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.

  • Intel® Inspector XE 2013 slows down my application significantly under memory checking and thread checking analysis. How can I make it faster?
  • 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.

  • I am already using the smallest data sets, but thread checking is still slow with my application. How can I make it run faster?
  • 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

  • I am using third-party code in my development. Can Intel® Inspector XE 2013 exclude the third-party binaries and focus on my code?
  • 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.

  • I don’t mind analyzing third-party modules but I don’t want to see problems in them. Can you hide problems in third-party binaries?
  • 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.

  • I have my own synchronization or memory management APIs. Can I still use Intel® Inspector XE 2013?
  • 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.

Intel® Inspector XE 2013

Getting Started?

Click the Learn tab for guides and links that will quickly get you started.

Get Help or Advice

Search Support Articles
Forums - The best place for timely answers from our technical experts and your peers. Use it even for bug reports.
Support - For secure, web-based, engineer-to-engineer support, visit our Intel® Premier Support web site. Intel Premier Support registration is required.
Download, Registration and Licensing Help - Specific help for download, registration, and licensing questions.

Resources

Release Notes - View Release Notes online!

Documentation:
Windows* | Linux*
Documentation for other software products

Featured Support Topics

No Content Found

Pages