LC Hotline: 2-4531

From offsite: (925) 422-4531

 

Hours

Monday–Friday
8am–12pm, 1–4:45pm
B453 R1103 | Q-clearance area

 

Intel Inspector

Intel Inspector is a code correctness tool that can identify threading and memory errors in C, C++, and Fortran codes. This tool replaces Intel's old Thread Checker tool, adding memory debugging capabilities and a standalone GUI. Inspector works by performing dynamic analysis (that is, instrumenting and analyzing execution at run time). It can detect intermittent and non-deterministic errors, even if the errors do not manifest themselves.

Platforms and Locations

Platform Location Notes
x86_64 CHAOS 5 /usr/local/tools/inspector* Multiple versions are available. Use Dotkit to load.
x86_64 TOSS 3 /usr/tce/packages/inspector/* Multiple versions are available. Use module to load.
BG/Q Not available  

Quick Start

For both thread debugging and memory debugging, Inspector can perform varying degrees of analysis. More in-depth analysis can capture a greater number of bugs but will also take longer to analyze. In general, slowdowns on the order of 2x to 160x can be expected. Thus, it is suggested that users choose a small, representative workload when running the tool rather than a full production workload.

Before getting started, compile your code with -g to get debug information and preferably -O0 to ensure the debug information accurately reflects the source code location. Inspector does not require use of Intel compiler. If you do use the Intel compiler, turn off compiler run-time checks such as -fmudflap or -check bounds.

Inspector includes both a graphical user interface (GUI) and a command line (CL) interface that can be accessed with the inspxe-gui and inspxe-cl commands, respectively. When running the GUI, begin by creating a new project, entering the executable path, arguments, environment variables, and setting other options. Once the Inspector project is created, set up a new analysis. For memory error analysis, there are three analysis types, from narrowest scope (lowest overhead) to widest scope (highest overhead): detect leaks; detect memory problems; locate memory problems. Similarly, for threading error analysis there are three analysis types, from narrowest scope to widest scope: detect deadlocks; detect deadlocks and data races; locate deadlocks and data races. The wider scopes are capable of identifying more errors but will take longer to run. Once the analysis type is configured, click "Start" to run the analysis. Note that there is also a "Show Command Line" button in the bottom right-hand corner that provides a handy way to generate the CL equivalent of your Inspector project and analysis configuration.

After the analysis completes, the GUI will bring up the Summary view. The Problems pane lists all of the potential errors that Inspector found. Click on a specific problem to display the corresponding source code for the selected problem below in the Code Locations pane. Note that depending on the error type, you may see multiple code locations (e.g., the two access sites in the case of a data race). Right click an item in the Problems pane for various actions such as obtaining a problem explanation or launching an editor on the source file in question. You can also change the state of the problem to confirmed, fixed, or not a problem, which can be helpful for tracking the status of the various issues. Finally, the Filters pane on the right side of the GUI allows you to filter the output by various categories such as problem type, library, or source file. (The GUI includes several other features, such as defining suppressions and comparing two analysis results.)

LC CHAOS Linux systems offer an MPI-enabled command line that can be accessed via inspxe-cl-mpi. This command takes the same arguments as the serial inspxe-cl command and will automatically append the MPI rank of each process to the name of the results directory. An example usage with MPI would be to run

srun -n 16 inspxe-cl-mpi -r my_result -collect mi3 -- my_mpi_app my_app_arg1 my_app_arg2

to create results directories my_result.0 through my_result.15. The inspxe-gui GUI does not provide a mechanism to run an analysis of MPI applications. The GUI also does not provide a way to view aggregated MPI results so each MPI task's results must be opened individually in the GUI. The 2017 version of Inspector includes a -trace-mpi option that also appends MPI ranks to results.

srun inspxe-cl -trace-mpi -r my_result -collect mi3 -- my_mpi_app my_app_arg1 my_app_arg2

This will create a my_result.hostname directory for each host that your MPI application is run on. You can then open the .inspxe file (one created per host) in each directory from the inspxe-gui GUI.

Tutorials

Inspector provides a tutorial in /usr/tce/packages/inspector/default/documentation/en/tutorials/index.htm or on Intel's Web site. The example C++ code in the tutorial can be found in /usr/tce/packages/inspector/default/samples/en/C++/tachyon_insp_xe.tgz, and the example Fortran code can be found in /usr/tce/packages/inspector/default/samples/en/Fortran/nqueens_fortran.tgz.

Documentation and References

The Inspector documentation can be found in /usr/tce/packages/inspector/default/documentation/en/welcomepage/get_started.htm or on Intel's Web site.

For more information, visit Intel's Inspector Web page.

LLNL-WEB-538671