Investigating and citing issues in the integration build
From current
Contents |
Your integration build analysis likely contains a long list of detected issues. Don't panic! This article shows you how to:
- handle a long list of detected issues
- investigate issues
- change the status of issues after you've investigated them, to indicate to others on your team how they should be handled
Prerequisite: An integration build analysis needs to exist before you can use Klocwork Review to investigate issues.
Viewing a list of issues in your integration build
You can get to a list of issues by:
- drilling down in a report
- searching
- clicking a link on the projects list
If you're not already looking at a list of issues, here's the easiest way:
- Log into Klocwork Review, if you haven't already done so.
- You see a list of projects for which you have permissions on the current Klocwork Server host and port.
- For any project in the list, click the New or Open issues link.
-
Understanding the issue list
Here's an issue list for the open-source project CVS:
What you see is controlled by:
- the current view, shown beside the project name. Any constraints on the list are noted to the right of the view name. Our example uses the default view, which in this example has no constraints.
- what appears in the Search field. In our example, because we clicked Open issues, the Search field reads: status:+Analyze,+Fix. If the build is not specified, issues from the most recent build are shown. See Searching in Klocwork Review for more information on search syntax.
Handling a long list of issues
The CVS project we're using as an example has 585 open issues. It would be difficult to investigate this many issues at once. There are several ways to make investigation easier:
- Views. Hover over the currently selected view and select another view if available, or select Manage views to go to the list of views for the current project. See Customizing your view of the integration build analysis.
-
- Searches. Pick a different search from the Searches list or edit the search query. See Searching in Klocwork Review for details on search syntax.
- Sorting. You can sort by ID, severity, state, status, code, file, entity or owner.
Investigating issues
Klocwork Review provides several tools to help you decide whether detected issues are actual defects in the context of your code. If you determine that the detected issues are real defects, Review also helps you decide how serious they are and when they should be fixed.
Click the description for an issue in the list or double-click anywhere on a row to view details for that issue.
Summary: The section at the top left provides quick information on the issue, with a link to help 
on the type of issue. You can right-click the issue ID number and copy a permanent link to include in bug reports or attach to emails.
Found in other projects list: If cross-project issue matching has been set up, you may see a list of other projects where this issue appears, along with the status for those issues, under the summary:
Traceback: The traceback section identifies and describes statements in the source code that contribute to the issue. Traceback lines link directly to the source code and follow execution order. Note that traceback may not be available for all issues. If you don't see any traceback for the error selected from the list of issues, it means that the problem associated with the issue is confined to one line of code.
Source viewer: The lines in the source file involved in the error are highlighted. The highlighted lines correspond to the currently selected traceback item. See Using the source viewer in Klocwork Review for information on using this powerful source viewer.
Now that you have more information about the issue, it's time to cite the issue by changing its status and adding comments.
Changing an issue's status to show how it should be handled
Once you've assessed detected issues, the next step is to change their status and add comments, to indicate how they should be handled.
Using statuses such as Not a Problem, Ignore or Defer is a handy way to suppress issues in your results that you don't care about (often in third-party libraries). Note that if you have determined that one or more detected issues are false positives, you should log a ticket with Customer Support.
You can change the status for one issue at a time, for selected issues, or for an entire list. You need the Change Issue Status permission to change issue status.
Once you change an issue's status to something other than Analyze or Fix, you won't see it again because default filtering options hide all issues in statuses other than Analyze and Fix. You can adjust the list by making another selection in the Searches list or by entering your own search query.
Changing the status for individual issues
In the left pane, select a status from the Status drop-down and add any relevant comments. Typically, if you decide that an issue doesn't need to be fixed, you select either Not a problem to indicate a false positive, or Ignore to indicate an issue that you don't care about (third-party libraries, for example). The status you select should reflect your organization's policy. For the full list of statuses, see Issue statuses.
Changing the status for multiple issues
Typically, you'd edit a single issue at a time if it required some investigation and you were dealing with a short list of them (as described above).
Other times it makes sense to edit many issues at once from the list of issues.
Changing the status for selected issues
For example, you may want to change the status for several issues at once in a particular file. In this case, you'd sort the issues by file in the list, Ctrl-click the issues you want to edit, and click Edit selected at the top of the list.
Changing the status for the whole list
Other times, you may wish to edit hundreds of issues at once, particularly when you're handling many issues in a third-party library and want to set all of them to Ignore. Or, your organization may have decided to establish what we call a baseline, by changing the status for all issues found in the integration build and then addressing only new issues.
Note: When you change issue status using edit all, issues in the list that match your search criteria and view are edited. Changing the status with edit all does not change the status for all issues in your build.
To change the status for the whole list of issues:
- Set up a view or use a search query that will list all the issues you wish to manage at once.
- Click Edit all at the top of the list.
- Select a status, add a comment, and click Submit.
Assigning ownership
If access control has been set up, or if file ownership has been configured, the Owner field appears in the issue details.
If file ownership has not been configured, issues will initially be displayed as "unowned", as shown here.
If you have the Change Issue Status permission, you can assign a new owner:
- from the issue details, by setting Owner
- from the issue list, by selecting one or more issues and clicking Edit Selected and setting Owner
- from the issue list, by clicking Edit All and setting Owner
Ownership changes are recorded in the issue history. For details on ownership, see Tracking issues by owner.
Viewing the history of an issue
Once you've changed the initial status of Analyze to another status or changed its owner, you can view an issue's history. In the issue list, issues that have changes have a view history icon 
, and a View history link appears in the issue details. Clicking the icon or link will show changes in the Status History dialog.
What's next?
Now that you understand how to investigate and cite issues in the integration build, you can:
- Learn how to tailor the analysis to your particular software project. See Tuning C/C++ analysis or Tuning Java analysis.
- Try the report designer.
See also
How-to
- Searching in Klocwork Review
- Customizing your view of the integration build analysis
- Using the source viewer in Klocwork Review
- Tracking issues by owner
- Managing project branches
Reference
Blog posts