[JIRA] (JENKINS-14821) warnings-plugin counts wrong

Mon, 03 Sep 2012 01:41:57 -0700

torbent commented on Bug JENKINS-14821

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...
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to