Suppression Rule Syntax in Text Format

Tip

  • Although you are ultimately trying to suppress problems, the vehicle for defining a suppression rule is one or more code locations.

  • Narrow rules suppress a limited number of relevant problems; wider rules suppress a greater number of relevant problems.

  • Every rule applied during analysis adds processing time.

  • The goal: Suppress the greatest number of relevant problems with the fewest number of rules.

  • To review rules to be applied during analysis, check the Suppressions tab of the Project Properties dialog box.

  • To apply rules during analysis, select the Apply Suppressions radio button on the Target tab of the Project Properties dialog box.

  • A code location may be part of multiple problems; therefore, multiple rules may suppress the same code location, or a rule created to suppress one problem may partially impact another problem.

Syntax

Each suppression rule consists of an optional name, optional problem type, optional allocation/deallocation site code location, and a stack/traceback with required and optional information in the following syntax:

Suppression = {
  Name = "<Rule name>";
  Type = { <problem-type> }
  Stacks = {
       allocation|deallocation = {
       mod=<module-name>, func=<function-name>, src=<source-filename>,
       line=<absolute-line-number>, func_line=<relative-function-line-number>;
    }
  }
}

For example: This rule suppresses any Memory not deallocated problem where the last-called frame in the problem stack is in the my_alloc function from the alloc.c source file.

Suppression = {
    Type = { reachable_memory_leak }
    Stacks = {
        {
            func=my_alloc, src=alloc.c;
        }
    }
}

Tip

  • Keywords values are case sensitive. For example: Type = { reachable_memory_leak } is valid; Type = { Reachable_memory_leak } is invalid.

  • Semicolons are optional except for at the end of the line (or set of lines) that describes a specific stack/traceback frame.

  • Insert comments using the pound sign (#) as the first non-space character on a line.

Type Keyword

Use Type to indicate a problem must match a specific problem Type to be suppressed.

You can identify one Type per rule or omit Type entirely. If you omit Type, the Intel Inspector matches any problem Type.

Tip

Omit Type to widen the reach of a rule.

Valid Type values include the following:

Type Descriptions

Corresponding Type Values

Cross-thread stack access

cross_thread_stack_access

Data race

datarace

Deadlock

deadlock

GDI resource leak

gdi_handle_leak

Incorrect memcpy call

invalid_call

Invalid deallocation

invalid_memory_unmap_notmapped

Invalid memory access

invalid_memory_access

Invalid partial memory access

invalid_memory_access_partial

Kernel resource leak

kernel_handle_leak

Lock hierarchy violation

potential_deadlock

Memory growth

intermediate_memory_leak

Memory leak

unreachable_memory_leak

Memory not deallocated

reachable_memory_leak

Mismatched allocation/deallocation

invalid_deallocation_mapped

Mismatched allocation/deallocation

mismatched_deallocation

Mismatched allocation/deallocation

invalid_memory_unmap_allocated

Missing allocation

invalid_deallocation

Uninitialized memory access

uninitialized_memory_access

Uninitialized partial memory access

uninitialized_memory_access_partial

Static analysis problems

Numeric problem code

Stacks Keyword

Use Stacks to indicate a problem must match a specific stack/traceback to be suppressed.

Each stack/traceback frame must contain at least one of the following: mod, func, src, or an ellipsis (...). You cannot include line or func_line without src. If you supply both line and func_line, the latter overrides the former. You can use the asterisk (*) wildcard when identifying modules, functions, and source files. Enclose function names that contain special symbols, such as commas, equation marks, and blanks, in quotation marks.

Use an ellipsis (...) to wildcard a set of frames (zero or more). Use a triple-bang (!!!) to match one or more unresolved frames, such as those for which a function name cannot be determined. (This maintains backward-compatibility with best location in previous Intel Inspector versions.) By default, matching starts with the last-called frame in the stack/traceback. If you want to match a frame somewhere in the stack/traceback, insert an ellipsis as the first frame.

Tip

  • Each additional frame in the stack/traceback narrows the reach of a rule.

  • Each additional keyword in a frame narrows the reach of a rule.

  • Suppression rules are more robust if you specify a stack/traceback with multiple frames instead of frames with line numbers. (Because line numbers can be altered by code insertions or deletions, suppressions may be rendered ineffective by even minor code maintenance. Stack-based suppressions require larger code changes to invalidate them, such as changes to function call sequences.)

Allocation and Deallocation Keywords

Use allocation or deallocation to indicate a frame must match an Allocation site or Deallocation site code location respectively for a problem to be suppressed.

You can include an allocation or deallocation keyword for each frame or omit the keywords entirely. If you omit the keywords, the Intel Inspector matches any code location in the frame.

Tip

Omit allocation and deallocation to widen the reach of a rule.

See Also


Supplemental documentation specific to a particular Intel Studio may be available at <install-dir>\<studio>\documentation\ .

For more complete information about compiler optimizations, see our Optimization Notice.