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.

Visible to Intel only — GUID: GUID-67937EA3-2EC5-436A-85EE-2248B3B4AF58

Document Table of Contents

Pane: Analysis Type-Memory Errors

Pane position in window

Before Analysis

(One way) To access this Intel Inspector pane:

  • From the Visual Studio* menu, choose Tools> Intel Inspectorversion> New Analysis.... Then choose Memory Error Analysis from the Analysis Type drop-down list.

  • From the Standalone Intel Inspector GUI menu, choose File > New > Analysis.... Then choose Memory Error Analysis from the Analysis Type drop-down list.

Use this pane on the Analysis Type window to:

  • Choose and, if necessary, fine-tune a preset memory error analysis type.

  • Configure a memory error analysis to investigate problems in an interactive debugging session.

TIP:
  • If the combination of analysis type settings in the preset memory error analysis types does not meet your needs at all, try creating a custom memory error analysis type.

  • Intel Inspector does not offer interactive debugging for the Detect Leaks analysis type because memory and resource leaks are determined after an application terminates and therefore cannot be used to halt execution during analysis. However, you can perform a standard debugger attach to a process launched under this analysis type.

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:

  • Review the analysis type settings for this analysis run.

  • Re-inspect - run another analysis using the same analysis type settings.

Use This

To Do This

Analysis Type drop-down list

Switch to another category of analysis types.

Configuration slider

Choose a preset analysis type (drag slider).

Analysis Time Overhead gauge

Analysis Time gauge

Quickly estimate the time it may take to collect a result using various preset analyses. Time is expressed in relation to normal application execution time.

For example, 2x - 20x is 2 to 20 times longer than normal application execution time. If normal application execution time is 5 seconds, estimated collection time is 10 to 100 seconds.

Memory Overhead gauge

Memory Overhead gauge

The Memory Overhead gauge helps you quickly estimate the memory the Intel Inspector may consume to detect errors using this preset analysis type. Memory is expressed in blue-filled bars.

NOTE:

The gauge does not show memory used by the running application during analysis.

Copy button

Create a new custom analysis type based on the currently selected analysis type.

Configurable Memory Error Analysis Type Settings

The following list shows the configurable settings (in alphabetical order) for preset memory analysis types. Configurable means you can change the setting without creating a custom analysis type:

  • Analyze stack accesses checkbox (configurable for the Locate Memory Problems analysis type only)

  • Detect leaks at application exit checkbox

  • Detect resource leaks checkbox

  • Detect still-allocated memory at application exit checkbox

  • Enable memory growth detection checkbox

  • Enable on-demand leak detection checkbox

  • Remove duplicates checkbox (configurable for the Locate Memory Problems analysis type only)

  • Stack frame depth drop-down list

Memory Error Analysis Type Settings

Use the Details region to review current analysis type settings. The following table describes the purpose, usefulness, and cost (low, medium, high, or proportional in terms of time and resources) for each memory error 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.