Sonar raise new issues on old code

SonarQube
,
1
  • Sonarqube 7.2, sonar-maven-plugin:3.7.0.1746
  • error observed: When scan the java code for the very fisrt time, there are no “new” issues. After some re analysis new issues are reopenned on old code without any code change nor rules or quality profiles. THis behaviour is very strange and we struggle tring to find out the root cause but in vain. Could you please help ?
2

Hi,

Welcome to the community!

7.2 is past EOL; you should upgrade immediately. Your upgrade path is:

7.2 → 7.9.4 → 8.5 (this step is optional)

Once you’re on a recent version, the docs about which issues are new and which are backdated may help.

 
Ann

3

I can confirm that this still happens in 8.6 (though it seems to happen much less than in 7.0). Issues don’t get reported until the second or third scan. At first I thought maybe the Maven scan failed on that specific file the first time and it went on to the next file, but I checked and all the other issues in that file were timestamped with the time of the first scan. The file in question is source code that has not been touched in a long time.

5

Hello @MisterPi

It can happen when you just upgraded SonarQube. New and modified rules can raise issues on old code.

Other than this guess, with this little information, it’s difficult to clearly identify the problem you are facing. Is it possible to provide more context: what rules are impacted? Do you see any pattern? Is there anything unexpected in the analysis logs? and so on… And ideally, a small project facing the issue?

6

I was responding to the OP, stating that the issue reported (issues not being caught the first time, but only after a later analysis, with no upgrades or rule changes to explain it) still exists. In my case it seems to be java:S2259 which sees this – that rule is for potential null pointer dereferencing. This happens in files that don’t change at all, so it’s not like a line somewhere in the file changed and that changed the analysis so it could no longer figure out that the object couldn’t be null and therefore flagged it.

7

I’m wondering how much interprocedural analysis SQ does, at least as far as null pointer analysis goes. I’m seeing another case of java:S2259 being flagged for the first time on code which hasn’t been touched in months. The issue occurs in a loop, where (for illustration) an object P is assigned L.get(i) where L is some kind of list and i is known to be a valid index (i iterates from 0 to L.size()-1). There are a few consecutive assignments, but ultimately the list comes from an object from a different class. So the question boils down to whether or not the list is guaranteed to contain only non-null elements.

So, for purposes of applying rule java:S2259, does SQ dive into other classes to try to determine if it is possible for the list to contain null elements?