Analyze invalid and uninitialized accesses to thread stacks. Enabling this setting is useful when:

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

High cost.

Recommendation:

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

Supported analysis:

mi3

Detect problems where an instruction reads or writes an uninitialized or invalid memory location. Enabling this setting is useful when an application:

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

Recommendation: Enable.

Supported analysis:

mi2, mi3

Enable this setting 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

). Enabling 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 the

Remove duplicates

checkbox selected.

Recommendation: Enable.

Supported analysis:

mi1, mi2, mi3

Enable this setting to detect open kernel and GDI handles when the application ends. For example, the application may open a file, get its handle, but never close or release that handle until it stops running. On Windows, GDI resources are limited, and the application may experience some drawing issues if it uses more than ~10,000 of these types of handles at once (pen, bitmap, brush, etc.).

Enabling is useful when analyzing Windows* GUI applications.

Low cost.

Recommendation: Enable the first time you analyze an application and periodically thereafter.

Supported analysis:

mi1, mi2, mi3

Set to true 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.

Enabling 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 Leak/Growth Detection

button and

Show Leaks/Growth Now

button during analysis.) Low cost.

Supported analysis:

mi1, mi2, mi3

Use this argument to set up the device on which your application executes during offloaded code analysis.

default
value does not change device settings and application execution control is defined by profiling process
cpu
value forces offloaded code regions to execute on a CPU during offloaded code analysis

Supported analysis:

mi1, mi2, mi3, ti1, ti2, ti3

Enable this setting to skip reporting races on guaranteed atomic operations on 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

. Use with caution, other architectures might have another policy on atomic operations.

Supported analysis:

ti2, ti3

Enable this setting to skip reporting races on guaranteed atomic operations on 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

. Use with caution, other architectures might have another policy on atomic operations.

Supported analysis:

ti2, ti3

Enable this setting to avoid showing duplicate occurrences of a detected problem in the

Code Locations

pane. Disabling 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: Enable.

Supported analysis:

mi3, ti3

Normal/normal=Set memory access byte granularity to 4 bytes, do not detect data races on stack accesses, and defer memory check. High cost.

Extremely thorough/extreme=Set memory access byte granularity to 1 byte, detect data races on stack accesses, and do not defer memory check. Extremely high cost.

Supported analysis:

ti3

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.

Supported analysis:

mi1, mi2, mi3, ti1, ti2, ti3

Detect problems where a still-reachable block of memory is allocated but not released when the application stops executing. Cost is proportional to the number of memory blocks still allocated when the application stops executing.

Recommendation: Enable this setting to investigate memory growth.

Supported analysis:

mi1, mi2, mi3

Stop analysis and application execution if the

Intel® Inspector

detects a deadlock. Enabling this setting is useful when running your application as part of a kernel or unit testing suite.

Low cost.

Recommendation: Disable. 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.

Supported analysis:

ti1, ti2, ti3

Potentially detect more data race and cross-thread stack access errors; however, do not optimize memory consumption and performance.

High cost.

Recommendation: Disable this setting to find most of your threading problems. After you find and fix the problems, enable the setting for more complete coverage.

Supported analysis:

ti3