States
To avoid investigating issues over and over again,
save your investigative conclusions by assigning states to the issues you
investigate.
State information is persistent within the
Intel Inspector
result, including when you reopen the result.
Intel Inspector
also propagates state information from an older result to a newer result when
you take advantage of various baseline result options.
Available States
Intel Inspector
offers the following states:
Filter Criterion
| Set By
| State
| Meaning
|
---|---|---|---|
Not investigated | Intel Inspector | ![]() Regression | The issue requires more investigation
because it was marked as
Fixed in the baseline result, but
still appears.
|
![]() New | The issue did not appear in the baseline
result, or there is no older result from which the
Intel Inspector
can propagate state information.
| ||
Intel Inspector
or User
| ![]() Not Fixed | The issue appeared in the baseline result
and still requires investigation.
| |
Investigated | User
| ![]() Confirmed | The issue requires fixing but has not yet
been fixed.
Report
Confirmed issues in a bug tracking
system.
|
![]() Fixed | The issue requires fixing and has been
fixed.
| ||
![]() Not a problem | The issue does not require fixing.
| ||
![]() Deferred | You are postponing further investigation
on an issue that may or may not require fixing.
|
Typical Usage Model
- Use the defaultGet problem states from previous result of same analysis typebaseline result option.
- Run an analysis.
- Use the filtering function to temporarily limit the displayed issues to only those that areNot investigated.
- Set the state of each problem issue you investigate as:
- Confirmed- Issue requires fixing but has not yet been fixed.
- Fixed- Issue requires fixing and has been fixed.
- Not a Problem- Issue does not require fixing.
- Deferred- Delay further investigation.
- The next time you rerun the analysis, verify the issues you expect to be fixed are indeed fixed.
State Propagation
Intel Inspector
propagates state information from the baseline result when it determines an issue in a new result corresponds to an issue in the baseline result. For example, if you set the state for a problem in the baseline result to
Not a Problem
, the
Intel Inspector
sets the state for the corresponding problem in the new result to
Not a Problem
.
The only exception: If you set an issue state to
Fixed
in the baseline result but the issue still
appears in the new result, the
Intel Inspector
sets the issue state to
Regression
in the new result.
Intel Inspector
may not recognize an issue as previously investigated when it propagates state information from a baseline result. This is more likely to happen when source code has undergone drastic changes between analysis runs.
States and Filters
Use the
Intel Inspector
filtering to focus on issues in specific states. For example, in the
Filters
pane on the
Summary
window:
- In theInvestigatedcategory, chooseNot investigatedto reduce clutter by displaying only issues with a state ofNew,Not fixed, orRegression.
- In theStatecategory, chooseConfirmedto review issues that are - or should be - reported in your bug tracking system.
- In theStatecategory, chooseNewto concentrate on issues introduced since the last analysis run.
- In theStatecategory, chooseRegressionto verify all issues marked asFixedin the baseline were successfully fixed.
- In theStatecategory, chooseNot a problemto double-check earlier conclusions that no fix is needed.
States Hierarchy
When you change the state of a problem set, the
Intel Inspector
responds by similarly changing the state of all problems currently in the
problem set.
In scenarios where a problem set contains problems
with different states (such as when source code changes introduce a new
instance of a problem previously set to a non-new state), the
Intel Inspector
assigns the most severe state to the problem set according to this hierarchy:
- Regression(most severe state)
- New
- Not Fixed
- Confirmed
- Fixed
- Not a Problem
- Deferred(least severe state)