Intel® Inspector User Guide for Windows* OS

ID 767798
Date 5/15/2022
Public

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

Document Table of Contents

Memory Error Analysis Types

Intel Inspector offers a range of preset memory analysis types to help you control analysis scope and cost:

  • Analysis types with the narrowest scope minimize the load on the system and the time and resources required to perform the analysis; however, they detect the narrowest set of errors and provide minimal details.

  • Analysis types with the widest scope maximize the load on the system and the time and resources required to perform the analysis; however, they detect the widest set of errors and provide context and the maximum amount of detail for those errors.

TIP:
  • Use analysis types iteratively. Start with a narrow scope to verify the application is set up correctly and set expectations for analysis duration. Widen the scope only if you need more answers and you can tolerate the increased cost.

  • Estimated collection time may be 2 to 160 times longer than normal application execution time.

  • Data set size and workload have a direct impact on application execution time and analysis speed.

Some settings in each preset analysis type are configurable. If the combination of settings in a preset analysis type almost meets your needs, try fine-tuning these configurable settings.

If the combination of analysis type settings in the preset analysis types does not meet your needs at all, try creating a new custom analysis type based on the currently selected analysis type.

Memory Error Configuration Settings for Each Preset Analysis Type

The following table shows the settings (in alphabetical order) for each preset analysis type.

  • N/A means not applicable for the preset analysis type (which means any value displayed in the GUI is greyed out)

  • Configurable means you can change the setting without creating a custom analysis type.

  • Renamed/split/combined configuration settings show previous manifestations.

Configuration Settings / Preset Memory Error Analysis Types

Detect Leaks (Narrow Scope)

Detect Memory Problems

Locate Memory Problems (Wide Scope)

Analyze stack accesses

N/A

No

No (configurable)

Defer memory deallocation (previously called Byte limit before reallocation)

N/A

N/A

1 Mb

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

No

Yes

Yes

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

Yes (configurable)

Yes (configurable)

Yes (configurable)

Detect resource leaks

Yes (configurable)

Yes (configurable)

Yes (configurable)

Memory Error Analysis Type Configuration Setting Descriptions

The following table describes the purpose, usefulness, and cost (low, medium, high, or proportional in terms of time and resources) for each analysis type configuration setting. (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.