Sonar 6 - new issues being flagged up in old source. Code hasn't changed, rules haven't changed.

[Ian Beaumont]

We have a daily scan on our Java source code using Sonar. Suddenly yesterday a few hundred new "bugs" appeared in code that hasn't been changed. I would have assumed that the bugs would have already been there after our initial scan and baseline of the project.
Nothing had changed, can anyone come up with a reason why this would happen and if there is anyway to correct it (ideally I need to mark these as already being in my baseline project as we are currently only interested in issues generated in changed code).
 I've tried deleting the analysis that detected them, but that didn't help.

The only strange thing that did happen, was that a new build was started while a sonar scan was in progress - so this could have caused compiled code to disappear/re-appear.

As you can see from the screen shot, the file had been originally anaylsed a month ago and had issues.  This file hasn't changed (nor have any of the classes it inherits from). So how can it suddenly detect new violations and why wouldn't they have been there before?  Other files have the same rule violations a month ago - so it isn't because the rules have been added.

Is there any known issue in Sonar that could cause this?

TIA

[Nicolas Peru]

Hi, 

If results have changed, something has to have changed on your setup. 

You ruled out (unintended pun) code and rules, please double check that the quality profile was not changed on your project nor the rules on that quality profile.

You may want to also check that no upgrade of the java analyzer took place.

One thing that could trigger a lot of issues is if for some reasons, you provided bytecode (compiled classes and dependencies) to the analysis. 

So did you change the configuration of the analysis ? how are you doing the analysis ? (which scanner, maven scanner ? and which version ? ) and what is the version of the sonar java analyzer you are using ?

Given what you are mentioning about compiled code :  some issues might have been closed by an analysis not using the bytecode and then reopened by the second one managing to use it.

All in all, there can be multiple causes to your issue so try to isolate what could have changed when things went messy and be precise about this.

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7a34bc1d-c62f-4a6c-b871-18215013429c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Ian Beaumont]

Hi Nicolas,
Thanks for the reply.

I've gone through everything I can think of checking for changes, and I can't see anything that has changed.

 - The quality profile hasn't changed (I can't image a way it could have possibly changed just to suddenly flag these changes on just these files).
 - No upgrades have taken place (again it wouldn't make much sense

We are using the scanner through Jenkins, v2.3 of the plugin.

The sonar java analyzer is version 4.2.

>> Given what you are mentioning about compiled code :  some issues might have been closed by an analysis not using the bytecode and then reopened by the second one managing to use it.

I think you've found the issue there.  I've searched through the closed issues, and have found them in there as fixed.  So I've now got the same issues as new. 
So is this how Sonar works...
-  if the byte code wasn't available during the analysis - it would close the issues that needed bytecode. 
- Then on the next scan, with the byte code being available again, it creates new issues.

If so, then I see an enhancement request that it shouldn't automatically close issues just because the bytecode has gone, but should flag them up as unable to determine if they still exist.

[Nicolas Peru]

Hi, 

So is this how Sonar works...
-  if the byte code wasn't available during the analysis - it would close the issues that needed bytecode.  
- Then on the next scan, with the byte code being available again, it creates new issues.

Hmm not quite... : when the bytecode is not available, semantic analysis is far less precise and as such the checks cannot fully rely on it. Then as a general rule of thumbs rules will not raise an issue if semantic is unprecise (we don't raise issue when we are not sure there is an issue to avoid false positive). 

So what seemed to have happen is issues were not reported by the analyzer running without bytecode because they weren't found, as such sonarqube (in charge of tracking issues) closed the issues. Then new analysis -> issues were reported properly -> new issue. 

This is related to the (hard) topic of issue tracking (nothing to do with the analyzer directly) and in this very case, I am not really sure it could be addressed. 

(The analyzer will run and report issues, then only SonarQube will try to track those issues between analysis).

Cheers, 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/c762e614-207c-4082-8fd0-10ce58f30096%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.