Intel® Inspector User Guide for Windows* OS

ID 767798
Date 3/31/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

Dialog Box: Custom Analysis

(One way) To access this Intel Inspector dialog box:

  • Click the Copy button on the Analysis Type-Memory Errors or Analysis Type-Threading Errors pane.

  • Click the Copy button or Edit button on the Analysis Type-Custom pane.

Use this dialog box to create or edit custom analyses.

Use This

To Do This

Analysis name field

View or change the default name that distinguishes this custom analysis type from other analysis types when you use the graphical user interface.

Description field

View or change the default detailed information that distinguishes this custom analysis type from other analysis types.

Command-line name field

View or change the default identifier that distinguishes this custom analysis type from other analysis types when you use the command-line interface.

Analysis identifier field

View or change the {at} identifier that distinguishes results produced by this custom analysis type from other results. For example: ti2c, where:

  • ti2 represents the preset analysis type on which the custom analysis type is based

  • c represents custom

Configuration Settings for Custom Analysis Types Based on Memory Error Analysis Types

Use the Properties region of the dialog box to configure the custom analysis type.

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

Setting

Purpose, Usefulness, and Cost

Analyze stack accesses

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.

Defer memory deallocation (previously called Byte limit before reallocation)

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.

Detect invalid memory accesses (split from Detect invalid/uninitialized accesses)

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.

NOTE:

May change application behavior by initializing memory that may normally be uninitialized. If your application reads this normally uninitialized memory, it may:

  • Simply miscalculate a value.

  • Treat the memory as a pointer, deference it, and crash during analysis.

Detect leaks at application exit (previously called Detect memory leaks upon application exit)

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.

Detect resource leaks

Select 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.)

Selecting is useful if you see constant growth in acquired kernel and GDI objects in the system task manager for your process.

Low cost.

Recommendation: Select unless you want to focus on memory problems exclusively.

Configuration Settings for Custom Analysis Types Based on Threading Error Analysis Types

Use the Properties region of the dialog box to configure the custom analysis type.

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.

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.

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.