Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2968

Findbugs reports some warnings as resolved even if this is not true

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • findbugs-plugin
    • None
    • Platform: All, OS: All

      Findbugs sometimes shows that a warning has been solved even if it is not true.
      I think that the problem is in cases when in resulting xml for one bug there are
      more ranges.
      In one build a warning has line ranges 276,268,256 and in next build has
      268,276,256. These is the same warning, the only difference is order of line
      ranges. AFAIK the difference between builds is based on hashes of warnings, then
      I think before building the hash you need to sort these line ranges. Hopefully
      this will remove those alerts.

      Thanks for this wonderfull plugin!

      An example build N:

      <bug>
      <message>Null value is guaranteed to be dereferenced</message>
      <priority>NORMAL</priority>
      <key>23046</key>
      <lineRanges>
      <range>
      <start>276</start>
      <end>276</end>
      </range>
      <range>
      <start>268</start>
      <end>268</end>
      </range>
      <range>
      <start>256</start>
      <end>256</end>
      </range>
      </lineRanges>
      <primaryLineNumber>276</primaryLineNumber>

      <fileName>/var/hudson/jobs/TinRead/workspace/trunk/src/sibimol/marcforms/entities/FixlenSequenceEditor.java</fileName>
      <moduleName>classes</moduleName>
      <packageName>sibimol.marcforms.entities</packageName>
      <category>CORRECTNESS</category>
      <type>NP_GUARANTEED_DEREF</type>
      <contextHashCode>23047</contextHashCode>
      <tooltip></tooltip>
      <instanceHash>ede3b3856ff9251282a6b08f48aaa842</instanceHash>
      </bug>

      After this build N+1:

      <bug>
      <message>Null value is guaranteed to be dereferenced</message>
      <priority>NORMAL</priority>
      <key>25551</key>
      <lineRanges>
      <range>
      <start>268</start>
      <end>268</end>
      </range>
      <range>
      <start>276</start>
      <end>276</end>
      </range>
      <range>
      <start>256</start>
      <end>256</end>
      </range>
      </lineRanges>
      <primaryLineNumber>268</primaryLineNumber>

      <fileName>/var/hudson/jobs/TinRead/workspace/trunk/src/sibimol/marcforms/entities/FixlenSequenceEditor.java</fileName>
      <moduleName>classes</moduleName>
      <packageName>sibimol.marcforms.entities</packageName>
      <category>CORRECTNESS</category>
      <type>NP_GUARANTEED_DEREF</type>
      <contextHashCode>25552</contextHashCode>
      <tooltip></tooltip>
      <instanceHash>ede3b3856ff9251282a6b08f48aaa842</instanceHash>
      </bug>

          [JENKINS-2968] Findbugs reports some warnings as resolved even if this is not true

          developster added a comment -

          Now I see that primaryLineNumber also differs, maybe this should the one with
          lowest line range?

          developster added a comment - Now I see that primaryLineNumber also differs, maybe this should the one with lowest line range?

          Ulli Hafner added a comment -

          Hmm, that is strange. I thought I'm using the instanceHash of the findbugs
          library to compare two bug instances. Does this occur in the released version of
          the plug-in? (The output seems to be from the TRUNK version, I'm currently
          experimenting to compute theses hashes on my own.). I'll need to investigate this...

          For the line ranges: here I'm also using the result of the findbugs library:
          They already define the primary line number. I'm not sure if this is
          deterministic in findbugs. However, sorting the ranges shouldn't be a big problem.

          Ulli Hafner added a comment - Hmm, that is strange. I thought I'm using the instanceHash of the findbugs library to compare two bug instances. Does this occur in the released version of the plug-in? (The output seems to be from the TRUNK version, I'm currently experimenting to compute theses hashes on my own.). I'll need to investigate this... For the line ranges: here I'm also using the result of the findbugs library: They already define the primary line number. I'm not sure if this is deterministic in findbugs. However, sorting the ranges shouldn't be a big problem.

          developster added a comment -

          I am using 1.3.7 version of findbugs.
          Instance hash seems to have correct hash, and in fact CI-game plugin calculates
          correctly the points, but the build status page there shows 1 fixed warning but
          when I click the warning it shows 0 warnings (url is
          .../TinRead/129/findbugsResult/fixed/)

          Results of findbugs, at least on my computer are surely nondeterministic. I
          think instance hash does not take into consideration line ranges
          (https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2009-January/002671.html)
          so it may be better to build another hash.

          Another thing to mention is that from previous examples, you see that findbugs
          reports 3 line ranges, but web interface shows me just what is in first (or in
          primaryLineNumber?!). Maybe there should be 3 warnings, instead of one?

          developster added a comment - I am using 1.3.7 version of findbugs. Instance hash seems to have correct hash, and in fact CI-game plugin calculates correctly the points, but the build status page there shows 1 fixed warning but when I click the warning it shows 0 warnings (url is .../TinRead/129/findbugsResult/fixed/) Results of findbugs, at least on my computer are surely nondeterministic. I think instance hash does not take into consideration line ranges ( https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2009-January/002671.html ) so it may be better to build another hash. Another thing to mention is that from previous examples, you see that findbugs reports 3 line ranges, but web interface shows me just what is in first (or in primaryLineNumber?!). Maybe there should be 3 warnings, instead of one?

          developster added a comment -

          I'm sorry. This is really just one warning, but just line ranges show more
          detailed info.

          developster added a comment - I'm sorry. This is really just one warning, but just line ranges show more detailed info.

          Ulli Hafner added a comment -

          Sorry, I meant if you use the released version of my findbugs plug-in? Or the
          trunk version...

          Ulli Hafner added a comment - Sorry, I meant if you use the released version of my findbugs plug-in? Or the trunk version...

          developster added a comment -

          I use released 1.3.7 version. It is not from trunk.

          developster added a comment - I use released 1.3.7 version. It is not from trunk.

          Ulli Hafner added a comment -

          1.3.7 is the version of findbugs! Current version of my plug-in is 3.3. Do you
          use the 3.3 version or a compiled version of the plug-in (not findbugs library)?

          Ulli Hafner added a comment - 1.3.7 is the version of findbugs! Current version of my plug-in is 3.3. Do you use the 3.3 version or a compiled version of the plug-in (not findbugs library)?

          developster added a comment -

          My bad I use version 3.3 of findbugs plugin. Not the trunk version.

          developster added a comment - My bad I use version 3.3 of findbugs plugin. Not the trunk version.

          Ulli Hafner added a comment -

          This should be fixed with JENKINS-6669. Please reopen, if your problem still remains.

          Ulli Hafner added a comment - This should be fixed with JENKINS-6669 . Please reopen, if your problem still remains.

            drulli Ulli Hafner
            developster developster
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: