[JENKINS-14821] warnings-plugin counts wrong

Type: Bug
Resolution: Fixed
Priority: Minor
Component/s: warnings-plugin
Labels:
None
Environment:
Jenkins 1.476, warnings 4.6 and 4.13

Similar Issues:
Powered by SuggestiMate

Show

This has been seen both with MSBuild, GCC, and custom parsers.
A build has e.g. 82 warnings, up from 65. On the build status page, it's reported as 28 new warnings and 11 fixed. When clicking through, I might get actual lists of 18 new and 1 fixed - that was the case the other day.
Today, when I look at that build, it apparently has forgotten all warnings and display any of them.
The custom parser has a tendency to report that all warnings are both new and fixed. At least it's e.g. 10 warnings, 10 new, 10 fixed. These warnings are given at file level, so I let them have line number 0. This used to work fine.

My users are rather impatient with regards to this, so it's hard to get a good consistent view of what's happening when I change something, but I'll try to see if I can get some "better" info.

SCM/JIRA link daemon added a comment - 2012-08-22 08:08

Code changed in jenkins
User: Ulli Hafner
Path:
pom.xml
src/test/java/hudson/plugins/warnings/parser/WarningTest.java
http://jenkins-ci.org/commit/warnings-plugin/6c04d695e3d27a06f52955a64f62bbc621066aed
Log:
~~JENKINS-14821~~ Added equals test.

SCM/JIRA link daemon added a comment - 2012-08-22 08:08 Code changed in jenkins User: Ulli Hafner Path: pom.xml src/test/java/hudson/plugins/warnings/parser/WarningTest.java http://jenkins-ci.org/commit/warnings-plugin/6c04d695e3d27a06f52955a64f62bbc621066aed Log: JENKINS-14821 Added equals test.

torbent added a comment - 2012-08-22 09:37

'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

torbent added a comment - 2012-08-22 09:37 '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

Ulli Hafner added a comment - 2012-08-23 12:50

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

Ulli Hafner added a comment - 2012-08-23 12:50 Well, the context hash code is not used in equals. All other properties are (besides of the message).

torbent added a comment - 2012-09-03 08:40

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

torbent added a comment - 2012-09-03 08:40 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...

Ulli Hafner added a comment - 2012-09-10 11:35

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

Ulli Hafner added a comment - 2012-09-10 11:35 Thanks for your input. I can now reproduce the problem.

SCM/JIRA link daemon added a comment - 2012-09-10 15:55

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

SCM/JIRA link daemon added a comment - 2012-09-10 15:55 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

SCM/JIRA link daemon added a comment - 2012-09-10 16:02

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.

SCM/JIRA link daemon added a comment - 2012-09-10 16:02 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.

SCM/JIRA link daemon added a comment - 2012-09-10 16:57

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.

SCM/JIRA link daemon added a comment - 2012-09-10 16:57 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.

torbent added a comment - 2012-12-13 09:41

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

torbent added a comment - 2012-12-13 09:41 Works for us now (well, for some time). Thanks for fixing.

Ulli Hafner added a comment - 2013-09-11 20:13

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

Result = SUCCESS

Ulli Hafner added a comment - 2013-09-11 20:13 Integrated in Jenkins Analysis Plug-ins (Compile) #609 [FIXED JENKINS-14821] : Fixed equals method. (Revision 7e5f781771b50a3e24b5c10f66fd72000a001adc) Result = SUCCESS

Assignee:: Ulli Hafner

Reporter:: torbent

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Created:: 2012-08-16 09:59

Updated:: 2013-09-11 20:13

Resolved:: 2012-09-10 15:55

Jenkins

Details

Description

Attachments

Activity

Collapse comment: SCM/JIRA link daemon added a comment - 2012-08-22 08:08

Expand comment: SCM/JIRA link daemon added a comment - 2012-08-22 08:08

Collapse comment: torbent added a comment - 2012-08-22 09:37

Expand comment: torbent added a comment - 2012-08-22 09:37

Collapse comment: Ulli Hafner added a comment - 2012-08-23 12:50

Expand comment: Ulli Hafner added a comment - 2012-08-23 12:50

Collapse comment: torbent added a comment - 2012-09-03 08:40

Expand comment: torbent added a comment - 2012-09-03 08:40

Collapse comment: Ulli Hafner added a comment - 2012-09-10 11:35

Expand comment: Ulli Hafner added a comment - 2012-09-10 11:35

Collapse comment: SCM/JIRA link daemon added a comment - 2012-09-10 15:55

Expand comment: SCM/JIRA link daemon added a comment - 2012-09-10 15:55

Collapse comment: SCM/JIRA link daemon added a comment - 2012-09-10 16:02

Expand comment: SCM/JIRA link daemon added a comment - 2012-09-10 16:02

Collapse comment: SCM/JIRA link daemon added a comment - 2012-09-10 16:57

Expand comment: SCM/JIRA link daemon added a comment - 2012-09-10 16:57

Collapse comment: torbent added a comment - 2012-12-13 09:41

Expand comment: torbent added a comment - 2012-12-13 09:41

Collapse comment: Ulli Hafner added a comment - 2013-09-11 20:13

Expand comment: Ulli Hafner added a comment - 2013-09-11 20:13

People

Dates