On our larger project, we have faced a situation where new bugs and new vulnerabilities have been reported on files which last modification are dated before the leak period starting point (the leak period is defined by version, the version being different at evry new analysis).
It appears that two specific analysis during the leak period generated these new bugs, but again without modifying these files.
This occured for various types of files, C and java mainly.
Could you list the rules in question? It’s likely that the new issues were caused by changes in other parts of the code. For example, if I remove the only use of a private method, that old method will get a validly new issue that it’s unused.
Thank you very much for considering this issue.
Some of the rules in question, for C language analysis, are those with the recommandation messages listed below.
I had to work from the issues list copy/paste output so don’t have the corresponding rules id.
But this helped me discovering one important potential cause of these issues marking as new: their lines number are wrong !!!
They are actually all out of the associated files number of lines:
L2591 for a file of 291 lines
L553 for a file of 42 lines
etc…
This applies to both C and CPP files.
As the line number is documented as part of the issues recognition from one build to another, my updated question is: in what circumptances can the sonarqube analyzers of server fail in reading issues line numbers ?
Notice that I need to concentrate on occurences of that problem related to the C language, as it corresponds to the most frequent and critical context for me.
Also I insist on the fact that the problem can occur when none of the related code (by far) has been modified. For instance memory allocation issues cannot be raised by any code change the whole modules related to these memory allocations were left untouched.
Here are some of the issues rules label as appearing on the issues lists tab:
(cpp) Review the data-flow; this memory allocation might not have been released when going out of scope.
(cpp) Remove the unary minus operator or change the expression’s underlying type.
(cpp) Catch the exception by reference.
(cpp) Remove this unreachable statement.
( c ) Change this condition so that it does not always evaluate to “true”; some subsequent code is never executed.
( c ) Review this data-flow; “shdr” is dereferenced and may be null.
( c ) Remove this unreachable statement.
My guess is that there was an upgrade of the underlying analyzer - to a smarter version - so it found new issues that were previously false negatives. I asked about your SonarQube version after seeing the rules in question because we did some significant work on issue backdating in the 7.x series. So once you upgrade to a current version - 6.7.5 is past EOL - you shouldn’t experience this in the future.
So you know, 7.9.2 is the current LTS, and 8.1 (8.2 drops any minute now) is the current version.
Thank you for this analysis.
The problem we had has occured without notice on analysis that are run daily, in a very steady sonarqube client and server context.
No analyzer upgrade on our side can be the cause of this random breaking of the reports.
Can you confirm us there is no known issue regarding c/cpp or generic source files parsing or data managemnet that could lead to some kind of source file content corruption into the sq analysis data, like the one we face with these irrelevant issues line numbers (as reported in a previous post) ?
If there is no known fix on c or generic files parsing that could be lead to false issues line numbering, it still appears likely to us that the problem will occur again after the upgrade to version 7.9.2 (which we are working on).