Coverity: Difference between revisions
No edit summary |
(Start to describe how we use Coverity) |
||
Line 10: | Line 10: | ||
* Up to C++14 (coverity 8.5.0.3 does not understand -std=c++1z) | * Up to C++14 (coverity 8.5.0.3 does not understand -std=c++1z) | ||
* No PCH (it somehow chokes on that) | * No PCH (it somehow chokes on that) | ||
== Inspecting the Results == | |||
=== Recommended Views === | |||
To see the contents of the overview page or email, use [[#All Newly Detected]] and [[#All Newly Fixed]]. | |||
==== All Newly Detected ==== | |||
This is the view you go to when Coverity informs that "new issues detected". We should strive to fix all newly-detected issues without undue delay. | |||
Probably a preset; if you deleted it, these are its settings: | |||
* Filters: | |||
** [x] Conparison | |||
*** (*) Absent | |||
* Snapshot Scope: | |||
** Show: last() | |||
** Compared to: lastBefore(last()) | |||
==== All Newly Fixed ==== | |||
To get an overview over what Coverity considers fixed. This may just mean code got moved around, and you'll find the same issue in [[#All Newly Detected]], so it's nice for cross-referencing (maybe the old issue was already triaged?). | |||
* Filters: | |||
** [x] Status | |||
*** [x] Fixed | |||
*** [x] Absent Dismissed | |||
* Snapshot Scope: | |||
** Show: lastBefore(last()) | |||
** Compared to: last() | |||
==== High Impact Outstanding ==== | |||
This is Marc's personal Coverity KPI. He wants to get this to zero count. | |||
* Filters | |||
** [x] Classification | |||
*** [x] Select All, then | |||
**** [ ] Intentional (unselect) | |||
**** [ ] False Positive (unselect) | |||
** [x] Component | |||
*** (to taste) | |||
** [x] Impact | |||
*** [x] High | |||
==== Fix Failed ==== | |||
This is a factor you can add to other views, like [[#High Impact Outstanding]], in order to see issues where the submitted fix has not caused the issue to be marked as Fixed in Coverity (yet). This includes the case where the patch just hasn't been merged, yet. But it can also find 2yr+ old fixes that ''actually'' failed to address the issue, and further fixed are required. | |||
* Filters: | |||
** [x] Action | |||
*** [x] Fix Submitted | |||
=== Triage === | |||
The goal should always be to make Coverity understand the code. If Coverity doesn't understand the code, it's likely humans don't, either. That means fixing the code is always preferable to saying False Positive or Intentional. | |||
Triage means to inspect the Coverity issue report and do one of three things: | |||
* If you understand what Coverity complains about ''and'' have an idea how to fix it, then | |||
** take responsibility for the issue and add your email address to the "owner" field | |||
*** We interpret Owner to be the owner of the issue, not the owner of the code the issue was found in | |||
** prepare a fix, upload to Gerrit | |||
*** reference Coverity-Id: <CID> in the footer of the commit | |||
** paste the Gerrit link into the "Ext. Reference" field | |||
** explain your findings in the Comment field in Coverity | |||
*** see Triage History for other comments | |||
*** note that a comment, once submitted, cannot be edited anymore, so be diligent | |||
** set the issue to Fix Submitted | |||
** set Classification to "Bug" or "Intentional" | |||
** select a Severity | |||
** Apply | |||
* You understand what Coverity complains about, but you don't have enough insight into the affected code to fix the issue yourself. Then | |||
** set Classification to "Pending" (or "Bug", if you see that it is) | |||
** leave Severity at Unspecified | |||
** set Action to "Fix Required" | |||
** create a Jira ticket with sufficient information that a developer that doesn't have access to Coverity can understand what the tool is complaining about; give solution alternatives, if you have them | |||
** paste the full Jira link (not just QTBUG-NNNNNN) into the "Ext. Reference" field | |||
** explain the issue in the comment field in sufficient detail that looking at Jira is not required (opening links from Ext. Reference is not very nice) | |||
** if you want to take responsibility for that a fix will eventually be made, even though you're not the assigner of the Jira ticket, add your email address to Owner | |||
** Apply | |||
* Finally, if you have no idea what Coverity is talking about, then | |||
** leave all fields unchanged | |||
** maybe share your thoughts in the comment field | |||
This list does not contain marking as False Positive, because that's not how we want to deal with these issues, cf. introductory remark. |
Revision as of 10:10, 21 March 2025
Parts of the Qt code base is scanned by Coverity, the results of which are available at https://scan.coverity.com/projects/qt-project.
Access to the scan results is limited to Qt approvers or maintainers (see The Qt Governance Model), or others whom a maintainer will acknowledge.
Building Qt for Coverity
A "default" configure line seems to be confusing Coverity. You may want to force:
- Up to C++14 (coverity 8.5.0.3 does not understand -std=c++1z)
- No PCH (it somehow chokes on that)
Inspecting the Results
Recommended Views
To see the contents of the overview page or email, use #All Newly Detected and #All Newly Fixed.
All Newly Detected
This is the view you go to when Coverity informs that "new issues detected". We should strive to fix all newly-detected issues without undue delay.
Probably a preset; if you deleted it, these are its settings:
- Filters:
- [x] Conparison
- (*) Absent
- [x] Conparison
- Snapshot Scope:
- Show: last()
- Compared to: lastBefore(last())
All Newly Fixed
To get an overview over what Coverity considers fixed. This may just mean code got moved around, and you'll find the same issue in #All Newly Detected, so it's nice for cross-referencing (maybe the old issue was already triaged?).
- Filters:
- [x] Status
- [x] Fixed
- [x] Absent Dismissed
- [x] Status
- Snapshot Scope:
- Show: lastBefore(last())
- Compared to: last()
High Impact Outstanding
This is Marc's personal Coverity KPI. He wants to get this to zero count.
- Filters
- [x] Classification
- [x] Select All, then
- [ ] Intentional (unselect)
- [ ] False Positive (unselect)
- [x] Select All, then
- [x] Component
- (to taste)
- [x] Impact
- [x] High
- [x] Classification
Fix Failed
This is a factor you can add to other views, like #High Impact Outstanding, in order to see issues where the submitted fix has not caused the issue to be marked as Fixed in Coverity (yet). This includes the case where the patch just hasn't been merged, yet. But it can also find 2yr+ old fixes that actually failed to address the issue, and further fixed are required.
- Filters:
- [x] Action
- [x] Fix Submitted
- [x] Action
Triage
The goal should always be to make Coverity understand the code. If Coverity doesn't understand the code, it's likely humans don't, either. That means fixing the code is always preferable to saying False Positive or Intentional.
Triage means to inspect the Coverity issue report and do one of three things:
- If you understand what Coverity complains about and have an idea how to fix it, then
- take responsibility for the issue and add your email address to the "owner" field
- We interpret Owner to be the owner of the issue, not the owner of the code the issue was found in
- prepare a fix, upload to Gerrit
- reference Coverity-Id: <CID> in the footer of the commit
- paste the Gerrit link into the "Ext. Reference" field
- explain your findings in the Comment field in Coverity
- see Triage History for other comments
- note that a comment, once submitted, cannot be edited anymore, so be diligent
- set the issue to Fix Submitted
- set Classification to "Bug" or "Intentional"
- select a Severity
- Apply
- take responsibility for the issue and add your email address to the "owner" field
- You understand what Coverity complains about, but you don't have enough insight into the affected code to fix the issue yourself. Then
- set Classification to "Pending" (or "Bug", if you see that it is)
- leave Severity at Unspecified
- set Action to "Fix Required"
- create a Jira ticket with sufficient information that a developer that doesn't have access to Coverity can understand what the tool is complaining about; give solution alternatives, if you have them
- paste the full Jira link (not just QTBUG-NNNNNN) into the "Ext. Reference" field
- explain the issue in the comment field in sufficient detail that looking at Jira is not required (opening links from Ext. Reference is not very nice)
- if you want to take responsibility for that a fix will eventually be made, even though you're not the assigner of the Jira ticket, add your email address to Owner
- Apply
- Finally, if you have no idea what Coverity is talking about, then
- leave all fields unchanged
- maybe share your thoughts in the comment field
This list does not contain marking as False Positive, because that's not how we want to deal with these issues, cf. introductory remark.