A bit of interesting (I hope) information:
When manually comparing compiler-1-warnings.xml files from two consecutive builds, I can see that some entries therein differ only on their <contextHashCode> elements (and <key>, but that seems rather universal). The number of contextHashCode differences matches the reported number of fixed/new warnings.
It would seem that the calculation of contextHashCode is not entirely consistent?

The contextHashCode is used to determine whether a warning is new. It is computed from the content of the file (+- 5 lines around the warning). So if all your warnings are at line 0 then the first lines should be read. Did the content of these lines change in that build?

Maybe the contextHashCode is not built at all: is the value of contextHashCode a numbered sequence of integers in one of your warning.xml files?

.

No, the contextHashCodes look random enough. One problem, though, is that for the dynamic parser where the line number is reported as 0, the filenames are equally invalid, i.e. there is actually no file by that name.
The (proprietary, home-grown) tool that outputs these warnings does not output file names, but class names, and there's no simple relationship from one to the other.
So with no file to read I could suspect that the hash code starts off uninitialised and never gets a proper value, perhaps? Maybe seeding it with hash(filename) might be an idea that would ensure some sort of difference between files, yet not depend on line number?

However, this doesn't really explain it for the MSBuild parser. I'll have to check the relevant source code (and I will).
It also does not explain why the lists of new/fixed warnings are actually empty even if there's supposed to be e.g. 10 of each (as reported by MSBuild parser).

By the way, I respect that you don't find this a major problem, but please keep in mind that my users actually do find it bordering on Blocker. I was forced to downgrade the plugin to keep them (partly) happy...

Oh, it turns out that you're right about the sequential integers.
For those (or: the number of) warnings where the plugin reports new+fixed, the contextHashCode is indeed just an integer, apparently from the same "number space" as the value of <key>.
For the unchanged warnings, the contextHashCode does look more random (much larger numbers, even negative).

The MSBuild parser warnings in question are reported for filenames (seen in <path> element) such as "" or "C:/Windows/Microsoft.NET/Framework/v4.0.30319". The latter file is not present on the machine that parses the warnings.

Perhaps warnings in inaccessible files (i.e. without a proper context) could be excluded from the new/fixed comparison?

Hmm, I still can't reproduce the problem. The new warnings are computed using the difference of 'current' - 'reference' using the equals method. I.e. if all properties are the same then the difference should return an empty set.

What did you set in option 'Use delta for new warnings' in the configuration of the plug-in?

'Use delta for new warnings' is unset.

The properties most likely are not the same - the contextHashCode has changed.

But even when the plugin reports e.g. "10 new" and "10 fixed", the lists of those new/fixed warnings are empty.

I'll see if I can make an easy-to-reproduce example for you

Well, the context hash code is not used in equals. All other properties are (besides of the message).

It has been difficult to reproduce consistently, so here's instead some details from a recent build.
I hope this can help locate and fix the problem. I'm still using warnings-plugin 4.6 ...

The job in question uses two parsers (MSBuild and a dynamic one). Both parsers read the same build log.

Looking at build #574, the dynamic parser reports 235 warnings (235 new, 228 fixed).
Visiting the job/574/warnings1Result page I get a list of 229 warnings (that's what the Total says; I didn't count).
On job/574/warnings1Result/new are 4 warnings and on job/574/warnings1Result/fixed is an empty list.

Whether it counts the "real" warnings or not, I would expect it to be consistent and display a list of 235 new warnings when it reports "235 new". Et cetera.

Moving to MSBuild parser, it reports 17 warnings (1 new, 1 fixed).
The job/574/warnings25result page lists 17 warnings, job/574/warnings25result/new has 0 warnings, as has job/574/warnings25result/fixed

Diff'ing 573/compiler-25-warnings.xml and 574/compiler-25-warnings.xml, the only different contextHashCode is in the record below. There are no other differences at all in the files, apart from the "key" element.
From 573:

<warning>
<message>Could not resolve this reference. Could not locate the assembly "Options". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [a_file_name.csproj]</message>
<priority>NORMAL</priority>
<key>29584</key>
<lineRanges>
<range>
<start>1360</start>
<end>1360</end>
</range>
</lineRanges>
<primaryLineNumber>1360</primaryLineNumber>
<fileName>C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Microsoft.Common.targets</fileName>
<moduleName></moduleName>
<packageName>-</packageName>
<category>MSB3245</category>
<type>MSBuild</type>
<contextHashCode>29585</contextHashCode>
<origin>warnings</origin>
<pathName>C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319</pathName>
<primaryColumnStart>0</primaryColumnStart>
<primaryColumnEnd>0</primaryColumnEnd>
</warning>

From 574:

<warning>
<message>Could not resolve this reference. Could not locate the assembly "Options". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [a_file_name.csproj]</message>
<priority>NORMAL</priority>
<key>31270</key>
<lineRanges>
<range>
<start>1360</start>
<end>1360</end>
</range>
</lineRanges>
<primaryLineNumber>1360</primaryLineNumber>
<fileName>C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Microsoft.Common.targets</fileName>
<moduleName></moduleName>
<packageName>-</packageName>
<category>MSB3245</category>
<type>MSBuild</type>
<contextHashCode>31271</contextHashCode>
<origin>warnings</origin>
<pathName>C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319</pathName>
<primaryColumnStart>0</primaryColumnStart>
<primaryColumnEnd>0</primaryColumnEnd>
</warning>

It's the first record in both files. It also appears to be the only record that has a "non-hash" contextHashCode:

$ grep contextHashCode 574/compiler-25-warnings.xml
<contextHashCode>31271</contextHashCode>
<contextHashCode>-2082545419</contextHashCode>
<contextHashCode>933875131</contextHashCode>
<contextHashCode>1466277609</contextHashCode>
<contextHashCode>-903131753</contextHashCode>
<contextHashCode>1698353063</contextHashCode>
<contextHashCode>-319996298</contextHashCode>
<contextHashCode>731236099</contextHashCode>
<contextHashCode>-533676129</contextHashCode>
<contextHashCode>-1226539927</contextHashCode>
<contextHashCode>1828441604</contextHashCode>
<contextHashCode>-951103677</contextHashCode>
<contextHashCode>-708350096</contextHashCode>
<contextHashCode>-1778170223</contextHashCode>
<contextHashCode>-442325474</contextHashCode>
<contextHashCode>187724429</contextHashCode>
<contextHashCode>1758033733</contextHashCode>

As an aside, every record in compiler-1-warnings.xml have non-hash hashes (lowest: 31301, highest: 31535).

To me it looks like the "key" and non-hash "contextHashCode" values are drawn from the same number generator, although not identically across runs.
Notice how the key changes from 573 to 574.

It suggests some sort of race condition where there might be a number of threads (or other async activities) going on, and the number is thus not drawn from the generator in a consistent order.
I initially thought this was related to having 2 parsers, but I get the same problem on other jobs with only 1 parser (gcc4, incidentally).

So, I've tried to create a test example that will enable you to reproduce the problem.
Starting with a single warning in a file that does not exist, I expanded until I get the problem on every build now. Yay!

Here's the setup:

• Clear workspace before start (or just rm * in build step)
• Build step contains this script:

  cat > buildlog.txt << LOG
  main.c: In function ‘main’:
  main.c:2:1: warning: control reaches end of non-void function [-Wreturn-type]
  main2.c: In function ‘main’:
  main2.c:2:1: warning: control reaches end of non-void function [-Wreturn-type]
  main2.c: In function ‘main’:
  main2.c:3:1: warning: control reaches end of non-void function [-Wreturn-type]
  main2.c: In function ‘main’:
  main2.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
  main.c: In function ‘main’:
  main.c:3:1: warning: control reaches end of non-void function [-Wreturn-type]
  main.c: In function ‘main’:
  main.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
  main.c: In function ‘main’:
  main.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
  main2.c: In function ‘main’:
  main2.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
  main3.c: In function ‘main’:
  main3.c:2:1: warning: control reaches end of non-void function [-Wreturn-type]
  main4.c: In function ‘main’:
  main4.c:2:1: warning: control reaches end of non-void function [-Wreturn-type]
  main4.c: In function ‘main’:
  main4.c:3:1: warning: control reaches end of non-void function [-Wreturn-type]
  main4.c: In function ‘main’:
  main4.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
  main3.c: In function ‘main’:
  main3.c:3:1: warning: control reaches end of non-void function [-Wreturn-type]
  main3.c: In function ‘main’:
  main3.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
  main3.c: In function ‘main’:
  main3.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
  main4.c: In function ‘main’:
  main4.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
  LOG

• A gcc4 warnings parser parses buildlog.txt

Symptom is continously 16 warnings with 16 new and 16 fixed. Both the list of new and of fixed warnings are empty.

There were no problems with 6 warnings in 1 file or 12 warnings over 2 files. It looks like it does not make a difference whether all warnings from one file are grouped together or, as here, are mixed with warnings from other files.

I hope this helps...

Thanks for your input. I can now reproduce the problem.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/analysis/core/AbstractAnnotationParser.java
src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java
http://jenkins-ci.org/commit/analysis-core-plugin/7e5f781771b50a3e24b5c10f66fd72000a001adc
Log:
[FIXED JENKINS-14821]: Fixed equals method.

Compare: https://github.com/jenkinsci/analysis-core-plugin/compare/13d87628c1c5...7e5f781771b5

Code changed in jenkins
User: Ulli Hafner
Path:
pom.xml
src/test/java/hudson/plugins/warnings/WarningsDifferencerTest.java
src/test/resources/hudson/plugins/warnings/issue14821.txt
http://jenkins-ci.org/commit/warnings-plugin/9152a9d243197a2522b547b082e05e8fbd57d92a
Log:
[FIXED JENKINS-14821]: Fixed equals method.

Code changed in jenkins
User: Ulli Hafner
Path:
pom.xml
http://jenkins-ci.org/commit/warnings-plugin/cff6a886ae0fc74760b03623099bbac8dac313dc
Log:
JENKINS-14821: Upgrade to analysis-core 1.47.

Works for us now (well, for some time). Thanks for fixing.

Integrated in Jenkins Analysis Plug-ins (Compile) #609
[FIXED JENKINS-14821]: Fixed equals method. (Revision 7e5f781771b50a3e24b5c10f66fd72000a001adc)

Result = SUCCESS