Intel® Inspector Help
|
Before Analysis (One way) To access this Intel Inspector pane: Choose File > New > Analysis.... Then choose Custom Analysis Types from the Analysis Type drop-down list. Use this pane on the Analysis Type window to:
During Analysis To access this pane: Click the Analysis Type button on the Navigation toolbar. Use this pane to review the analysis type settings for this analysis run. After Analysis Is Complete To access this pane: Click the Analysis Type button on the Navigation toolbar. Use this pane to:
|
Use This |
To Do This |
---|---|
Analysis Type drop-down list |
Switch to another category of analysis types. |
Custom analysis type selection box |
Choose an existing custom analysis type. |
Copy button |
Create a new custom analysis type based on the currently selected analysis type. |
Edit button |
|
Delete button |
|
Analyze without debugger radio button |
Select to run an analysis without launching an interactive debugging session. Useful for investigating all types of memory and threading problems. TipYou can later use the Debug This Problem function from within a result to launch a new analysis in conjunction with a debugger to stop at problems of interest. The rerun analysis is automatically focused to find the selected problems, making it return to the problems more quickly. The Debug This Problem function is the recommended method for investigating threading errors in an interactive debugging session. |
Enable debugger when problem detected radio button |
Select to allow investigation of every problem detected in an interactive debugging session. Useful for investigating all types of memory problems except memory and resource leaks. |
Select analysis start location with debugger radio button |
Select to allow investigation of problems in a particular area of code during an interactive debugging session. Typical scenario: You need to check for errors in a specific section of application code, but the Intel Inspector does not provide the appropriate granularity to analyze only that code section. This option quickly takes you near that execution point in a debugging session. Useful for investigating all types of memory problems except memory and resource leaks. TipYou can also use this option to investigate all types of threading errors, but it may be quicker to use the Debug This Problem function in a result if you plan to investigate a single threading problem. |
The following table describes the purpose, usefulness, and cost (low, medium, high, or proportional in terms of time and resources) for each configuration setting in a custom analysis type based on a memory error analysis type. (The settings are listed in alphabetical order.)
The following table describes the purpose, usefulness, and cost (low, medium, high, or proportional in terms of time and resources) for each configuration setting in a custom analysis type based on a threading error analysis type. (The settings are listed in alphabetical order.)
Setting |
Purpose, Usefulness, and Cost |
---|---|
Cross-thread stack access detection |
Use to set the alert mechanism for when a thread accesses stack memory of another thread. The alert mechanism helps you decide if this is an issue that requires handling. All options are low cost if Detect data races is selected.
|
Detect data races |
Select to detect problems where multiple threads access the same memory location without proper synchronization and at least one access is a write. Selecting is useful when you suspect data races that are not yet evident. High cost. Recommendation: Select. Consider also deselecting Use maximum resources to reduce cost. |
Detect data races on stack (previously called Detect data races on stack accesses) |
Available only if Detect data races is selected. Select to detect data races for variables allocated on the stack. Selecting is useful when threads in an application share variables from the stack and you suspect data races on the variables. High cost. Recommendation: Deselect. If you select, consider also deselecting Use maximum resources to reduce cost. |
Detect deadlocks |
Select to detect problems where two or more threads are waiting for the other to release resources, but none of the threads releases the resources. Thus no thread can proceed. Selecting is useful when you want to troubleshoot the location of a deadlock. Low cost. |
Detect lock hierarchy violations |
Select to detect problems where the acquisition hierarchy order of multiple synchronization objects in one thread differs from the acquisition hierarchy order in another thread, and could cause a deadlock under certain conditions. Selecting is useful when an application has complicated synchronization and it is hard to verify correctness. Low cost unless an application has a significant number of locks. |
Race analysis byte granularity (previously called Memory access byte granularity) |
Available only if Detect data races is selected. Use to set the size of the smallest memory block the Intel Inspector considers a single block of memory when determining if non-synchronized accesses to a memory block constitute a data race. Selecting is useful to control memory consumption during analysis for some applications. High cost when set to 1 byte. Recommendation: Set to 4 unless you continually see data races based on safe access to smaller memory blocks. If so, reset to 1. |
Remove duplicates |
Deselect to show all occurrences of a detected problem in the Code Locations pane.
Recommendation: Select. |
Save stack on first access |
Available only if Detect data races is selected. Select to show as much information as possible on all threads involved in a data race. Selecting is useful when investigating complex data race problems. High cost. Recommendation: Deselect on initial analysis runs. Select only when you need the maximum information and context about all threads involved in a data race to solve the problem. |
Save stack on lock creation |
Select to show creation information on synchronization objects involved in deadlocks, lock hierarchy violations, and data races. Selecting is useful when acquisition stacks are not sufficient to understand the problem. Low cost. |
Save stack on memory allocation (previously called Save stack on allocation) |
Available only if Detect data races is selected. Select to identify the allocation site of dynamically allocated memory objects involved in data races. Medium cost. Recommendation: Select when you need to identify the object hierarchy of low-level objects involved in data races. For example: If object R is involved in a data race and is instantiated within objects O1, O2, and O3, the allocation call stack can help you identify which encapsulating object is not properly protecting access to object R. |
Stack frame depth |
Use to provide more or less call stack context for detected errors. A high setting is useful when analyzing highly object-oriented applications. A higher number does not significantly impact cost with one exception: Choosing a higher number plus selecting Save stack on first access increases cost. Recommendation: Use only as large a value as an application requires to display complete call paths. |
Terminate on deadlock |
Available only if Detect deadlocks is selected. Select to stop analysis and application execution if the Intel Inspector detects a deadlock. Selecting is useful when running your application as part of a kernel or unit testing suite. Low cost. Recommendation: Deselect. Instead, use the corresponding knob in the command line interface to perform kernel or unit testing in a nightly scenario. If the Intel Inspector identifies a deadlock, decide if it is appropriate to continue analysis. |
Use maximum resources |
Select to potentially find more problems. High cost. Recommendation: Deselect to run a quicker analysis that should find most of your data race and cross-thread stack access problems. Once you have found and fixed these problems, select to get more complete analysis coverage of possible data race and cross-thread stack access problems. |