Re: [dpdk-dev] New Coverity warnings

["Mcnamara, John" <john.mcnamara@intel.com>]

Hi,

Stephen, thanks for highlighting this.

For the last few analysis runs I have been generating some automatic emails from these summary emails and git blame. There is an example below.

I'd like to do this for all of the open defects but can't find a way to generate a similar report for existing defects. Also, assigning defects within the web app doesn't seem to email the assignee. The open source version of Coverity scan doesn't seem to have a web services interface like the commercial version (you get what you pay for) so I can't easily query it.

If anyone knows more about automating Coverity scan let me know.

But as Stephen says there are a lot of low-lying fruit that could be fixed:

    http://scan.coverity.com/projects/dpdk-data-plane-development-kit

John.


P.S. Sample email based on Coverity report:



Hi,

This is an automated email in relation to a new Coverity static code analysis
issue in DPDK. Details of the issue are below.

The email has been sent to you because you have been identified as the author
or maintainer of the code where the defect appears.

There are several possible scenarios:

* The defect identified isn't a real issue: In this case you can edit the
  defect online and change the defect "Classification" to "False Positive" or
  "Intentional" and change the "Action" to "Ignore". You should also update
  the "Severity", add yourself as the "Owner" and add a comment note.

* The defect is a real issue: In this case you should submit a patch to fix
  the issues. The patch should include the following information in addition
  to the usual comments and signoff:

    Coverity issue: 120412
    Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding dynamically")

  In Coverity you should update the Classification, Severity, Action (to "Fix
  required" or "Fix Submitted"), Owner and a Comment if necessary.

* The defect wasn't introduced by you. The line where the defect occurs may
  not be the source of the defect. If this is the case then let the actual
  author of the defect know by forwarding this email with a note or reply to
  the sender of this automated email: <john.mcnamara@intel.com>

You can review the defects online at:

    http://scan.coverity.com/projects/dpdk-data-plane-development-kit

If you aren't registered for the DPDK Coverity you can do so here:

    http://scan.coverity.com/users/sign_up

Git commit data and Coverity defect information below.

Commit data
===========

Commit: examples/ip_pipeline: reconfigure thread binding dynamically
Id:     b4aee0fb9c6d4fee771271d6c03a65dc27ba024a
Author: Piotr Azarewicz
Email:  piotrx.t.azarewicz@intel.com
Date:   Thu Oct 29 15:36:53 2015 +0100

Defect information
==================

/examples/ip_pipeline/thread_fe.c: 338 in app_pipeline_thread_cmd_push()
*** CID 120412:  Code maintainability issues  (SIZEOF_MISMATCH)
332             /* Check for available slots in the application commands array */
333             n_cmds = RTE_DIM(thread_cmds) - 1;
334             if (n_cmds > APP_MAX_CMDS - app->n_cmds)
335                     return -ENOMEM;
336     
337             /* Push thread commands into the application */
>>>     CID 120412:  Code maintainability issues  (SIZEOF_MISMATCH)
>>>     Passing argument "&app->cmds[app->n_cmds]" of type "cmdline_parse_ctx_t *" and argument "n_cmds * 8UL /* sizeof (cmdline_parse_ctx_t *) */" to function "memcpy" is suspicious. In this case, "sizeof (cmdline_parse_ctx_t *)" is equal to "sizeof (cmdline_parse_ctx_t)", but this is not a portable assumption.
338             memcpy(&app->cmds[app->n_cmds],
339                             thread_cmds,
340                     n_cmds * sizeof(cmdline_parse_ctx_t *));
341     
342             for (i = 0; i < n_cmds; i++)
34