Available only if

Detect invalid memory accesses

is selected.

Select to analyze invalid and uninitialized accesses to thread stacks.

Selecting is useful when:

You want as thorough an analysis as possible.
An application calls
alloca()
.

High

cost

.

Recommendation:

Select the first time you analyze an application and periodically thereafter.
Select to analyze automatic variables.

Available only if

Detect invalid memory accesses

and

Enable enhanced dangling pointer check

are selected.

Select to have the

Intel Inspector

prevent freed memory blocks from immediately returning to the pool of available memory.

Selecting is useful for discovering if an application tries to use memory after freeing it.

High

cost

if an application is performing many allocations/deallocations.

Recommendation: Select to improve analysis quality if the cost is not too high.

Select to detect problems where a read or write instruction references memory that is logically or physically invalid.

Selecting is useful to ensure an application accesses only valid memory.

Medium

cost

.

Recommendation: Select.

Select to report typical memory leaks in which the application allocates a memory block, never releases it, and doesn’t keep a pointer to the block (e.g.

unreachable memory blocks

).

Selecting is useful when an application:

Runs out of memory.
Appears to be using more memory than expected.

Extremely low

cost

– especially if used only with

Remove duplicates

selected.

Recommendation: Select.

Available only if

Detect leaks at application exit

is selected.

Select to report typical memory leaks in which the application allocates a memory block, doesn’t deallocate it, but a valid variable still holds a pointer to that block when the application ends (e.g.

reachable memory blocks

).

Cost

is proportional to the number of memory blocks still allocated when the application stops executing.

Recommendation: Select to investigate memory growth.

Available only if

Detect invalid memory accesses

is selected.

Select to detect problems where a read instruction accesses an uninitialized memory location.

Selecting is useful when an application:

Exhibits unexpected behavior.
Shows evidence of uninitialized values in computations.

High

cost

.

Recommendation: Deselect.

Available only if

Detect invalid memory accesses

is selected.

Select to detect if an application is trying to access memory after it was logically freed.

May be higher

cost

if an application is performing many allocations/deallocations, and the

Defer memory deallocation

list value is smaller than the amount of memory the application allocates.

Recommendation: Select when an application exhibits unexpected behavior you suspect may be caused by a dangling pointer.

Available only if

Detect invalid memory accesses

is selected.

Use in conjunction with

Guard zone size

to show offset information if the

Intel Inspector

detects memory use beyond the end of an allocated block.

Selecting is useful when:

An application exhibits unexpected behavior.
You need more context about heap allocations to interpret
Invalid memory access
problems.

Cost

is proportional to number of allocations.

Recommendation: Select unless:

Intel Inspector
runs out of memory.
An application becomes destabilized.

Select to enable buttons in the GUI that let you send commands during application execution. This will show you a list of

reachable and unreachable memory blocks

for a time segment.

Selecting is useful for modeling memory usage patterns and ensuring a transactional application deallocates all memory allocations after a transaction completes.

Use in conjunction with the

Reset Growth Tracking

and

Measure Growth

buttons during analysis.

Low

cost

.

Select to enable buttons in the GUI that let you send “leak” commands. This will show you a list of

unreachable memory blocks

for a time segment.

Selecting is useful for checking for memory leaks in an application that never exits, or in only the portion of an application for which you are responsible.

Use in conjunction with the

Reset Leak Tracking

and

Find Leaks

buttons during analysis.

Cost

is proportional to the number of allocations.

Available only if

Detect invalid memory accesses

and

Enable guard zones

are selected.

Use in conjunction with

Enable guard zones

to set the number of bytes beyond the allocated block of memory the

Intel Inspector

reserves to identify

Invalid memory access

problems related to the allocation.

Setting is useful when:

An application exhibits unexpected behavior.
You need more context about heap allocations to interpret
Invalid memory access
problems.

Cost

is proportional to number of allocations.

Recommendation: Set unless:

Intel Inspector
runs out of memory.
An application becomes destabilized.

Use to set the maximum number of leaks the

Intel Inspector

shows in a result after analysis is complete.

A zero setting shows all detected memory leaks.

Cost

is proportional to the number of leaks.

Recommendation: Use the default value unless you want an exhaustive list of all leaks.

Deselect to show all occurrences of a detected problem in the

Code Locations

pane.

Deselecting is:

Useful when you need to fully visualize all threads and problem occurrences in relation to time
Low
cost
in terms of time; however, the number of duplicate errors could crowd out the number of unique errors.

Recommendation: Select.

Available only if

Detect uninitialized memory reads

is selected.

The current algorithm for detecting uninitialized memory reads decreases false positives but increases analysis time and memory overhead. Select to use the previous version of the algorithm.

Recommendation: Deselect.

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

.

Recommendation: Use only as large a value as an application requires to display complete call paths.

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.

Recommendation:

Use
Hide problems/Hide warnings
if using an OpenMP* or oneAPI Threading Building Blocks (oneTBB) programming model; or if cross-thread stack accesses are anticipated. Also select
Detect races on stack
.
Use
Hide problems/Show warnings
if cross-thread stack accesses are not anticipated. Also deselect
Detect data races on stack
.
Use
Show problems/Hide warnings
if cross-thread stack accesses are not anticipated but a previous analysis indicated they exist and you are not using an OpenMP* or oneAPI Threading Building Blocks (oneTBB) programming model. Also deselect
Detect data races on stack
.

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.

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.

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

.

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.

Available only if

Detect data races

is selected.

Select to ignore data races on guaranteed atomic operations on the Intel® P6 processor family or newer. For details, please refer to the

Guaranteed Atomic Operations

section of the

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A

.

Selecting is useful if you observe many false data race reports on simple operations like Load or Store to shared variables and the size of those variables is less than the processor cache line size.

Do not select this option if you develop cross-platform code that should work on other architectures.

Selecting this option might also hide true-races on variables that were properly aligned during this run but might not be aligned in general, e.g., if it just works “by chance”.

Low

cost

.

Recommendations: Use this option with caution only if you observe many false reports on simple memory operations.

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.

Deselect to show all occurrences of a detected problem in the

Code Locations

pane.

Deselecting is:

Useful when you need to fully visualize all threads and problem occurrences in relation to time
Low
cost
in terms of time; however, the number of duplicate errors could crowd out the number of unique errors.

Recommendation: Select.

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.

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

.

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.

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.

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.

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.