Not fixed as far as I can see in 1.18

I have a report with 1 "error", 93 "warning", 56 "performance" and 152 "style" rows.
However, the summary table lists 0 for "Warning" and "Performance", and 149 for "No category".

The Advanced configuration is unchanged from the default, with no thresholds and all boxes ticked.

Hi James,

please attach or send me config.xml (job directory), build.xml (build directory), cppcheck_details.xml (build directory), source cppcheck report (workspace directory) and maybe screenshot of configuration page. If there are any sensitive data, please delete them or send me at least cppcheck related parts of the files. What version of Jenkins core and cppcheck do you use and on which platform?

Thank you,
Michal

Attached extracts from requested files.
Jenkins is 1.569 running on CentOS 6.

Hmmm, I'm absolutely unable to reproduce the issue, everything works for me. I tried the following:

• Debian testing, OpenJDK 7u55, Jenkins 1.447, latest git version of cppcheck plugin (~1.18), mvn hpi:run, cppcheck 1.61.
• New job with content of your config.xml from xml_extracts.txt.
• My own cppcheck-result.xml generated using "cppcheck --enable=all --inconclusive --xml --xml-version=2 graphal/graphal_gui 2> cppcheck-result.xml" that contains warning, style, performance and information severities.
• Content of generated files contains everything as expected and Jenkins presents the data correctly.
• Zipped job directory is attached as JENKINS-17450.tar.gz.

New questions:

• What Java do you use (6/7/8, Oracle, OpenJDK, IBM, ...)? Please use "java -version" command.
• What version of cppcheck do you use? Please use "cppcheck --version" command.
• What command do you use to execute cppcheck and to generate the report passed to the plugin? Are you using XML version 2 as suggested at wiki?
• Are you sure all files in xml_extracts.txt belong to the same job/build? I of course expect yes, I'm asking because:
  • Your build.xml contains zero performanceCount/warningCount but cppcheck_details.xml contains them. The files are created from the same data source in publisher so they should correspond each other.
  • Plugin version 1.18 should be able to handle all severities (I check it with cppcheck 1.61 and 1.63 several months ago), so noCategoryCount (~other/unknown category) should be always zero at least for these versions. But it is 149 in your case. The value probably contain warning, performance etc. ones, but I have no idea why
• Can you find any significant difference between your job directory and the one in JENKINS-17450.tar.gz?
• Please
  • Create a new job with cppcheck analysis of https://github.com/mixalturek/graphal.
  • Perform several builds.
  • Remove code of https://github.com/mixalturek/graphal from workwpace to have a smaller archive.
  • Zip whole job directory as I did for JENKINS-17450.tar.gz and attach it.

Thank you!

Master:
java version "1.7.0_55"
OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

Example slave:
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)
Cppcheck 1.57

Other slave with same problem (on different jobs):
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
Cppcheck 1.61

Cppcheck command:
cppcheck -i$PATH1 -i$PATH2 -i$PATH3 --xml --enable=style -j 2 $PATH4 2> cppcheck-int.xml
xsltproc cppcheck.xslt cppcheck-int.xml > cppcheck-result.xml

The XSLT is changing some "style" issues to "warning" and "performance". According to comments, this is because the --xml option changed everything that wasn't an "error" into "style". I can't see a logical reason why this would affect your plugin.

I'll try upgrading cppcheck and look at the options you recommend. This may prove the XSLT to be unnecessary and fix the count issue as well.
If that doesn't help, I'll try the test jobs you asked for.

Yes, switching to --xml-version=2 solves the problems.

Oh, I understand now. Legacy XML v1 format uses severities that are not compatible with new XML v2. There is the following mapping in the plugin code.

            if ("possible error".equals(cppcheckFile.getSeverity())) {
                warningSeverityList.add(cppcheckFile);
            } else if ("style".equals(cppcheckFile.getSeverity())) {
                styleSeverityList.add(cppcheckFile);
            } else if ("possible style".equals(cppcheckFile.getSeverity())) {
                performanceSeverityList.add(cppcheckFile);
            } else if ("error".equals(cppcheckFile.getSeverity())) {
                errorSeverityList.add(cppcheckFile);
            } else {
                noCategorySeverityList.add(cppcheckFile);
            }
            allErrors.add(cppcheckFile);

You should always use XML v2. Cppcheck for example reports less issues with XML v1 than with XML v2 for the same analyzed code.

Rejected, the issue can't occur without manual modification of the input report.

Maybe add a warning if the plugin detects the v1 format, but that'll be a separate ticket.

Simple but great idea, JENKINS-24007 created, thanks