Coverity

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
• 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.

Assorted Tips & Tricks

• Coverity has the dashboard, then the project overview, and then the "View Defects" part. The latter likes to get stale (maybe some auth token expires), but it won't tell you. It will just sit there and appear loading issues forever. In that case, you need to close that view and open it again from the project overview page. F5, for me, leads to a login dialog that never works (YMMV).