Since last monday (November 12th 2018), it appears that sonarcloud plugin repo has been updated and SonarCFamily plugin went from 5.1.1 to 6.0.
This new plugin version made popping a lot of new code smells in our project and a great part of these new issues are false positive (+112 issues, 108 false positives) essentially on 3 rules :
Methods should not be empty (cpp:S1186)
Nested blocks of code should not be left empty (cpp:EmptyCompoundStatement)
Init-declarator-lists and member-declarator-lists should consist of single init-declarators and member-declarators respectively (cpp:SingleDeclarationPerStatement)
Yes, deploying the new version of the CFamily plugin on SonarCloud was done on purpose, as one of the preliminary steps before making this major release available to all our users.
The issues you are showing indeed look strange, and we would like to understand where they may come from. Can you share with us your analysis logs? Is this code part of a public project that we might look at?
14:58:58.270 ERROR: [pool-3-thread-1] /usr/local/include/process-template/AbstractAlarms.hpp:11 'string' file not found
14:58:58.326 ERROR: [pool-3-thread-1] /home/stanislas/workspace/embedded/bgm/src/MyProcess.cpp:8 'sys/time.h' file not found
14:58:58.683 ERROR: [pool-3-thread-1] /usr/local/include/proto-messages/messages.pb.h:7 'string' file not found
14:58:58.807 ERROR: [pool-3-thread-1] /home/stanislas/workspace/embedded/bgm/src/BS.h:11 'utility' file not found
14:58:58.858 ERROR: [pool-3-thread-1] /home/stanislas/workspace/embedded/bgm/src/BM.cpp:10 'iostream' file not found
If you have missing files, you’ll have an incomplete analysis, which can lead to issues such as the ones you reported. Now the question is: Why do you have those missing files?
Well, a few lines before, one can see that when trying to ask your compiler what are its include paths, he answers in French, while we currently only understand it if itanswers in English. So, there probably be an easy workaround: Set the compiler output to English before running the analysis.
Please note that this behaviour has not changed at all in the last update of the plugin, so all your previous analyses were probably already suffering from the same configuration issue. What has changed is that the consequences of these issues are no longer the same.
Actually language was the point, according to the last version of our code :
With LANG=fr_FR.UTF-8 : 118 code smells with 90% of false positive
With LANG=en_GB.UTF-8 : 21 code smells with 0% of false positive and some new true issues…
Furthermore when language is set to english, missing files are found ?! I no more have “file not found” error.
Can’t explain why the behaviour wasn’t the same with previous version of the plugin…
So our problem is almost solved, I now have to check our Jenkins environment but thanks a lot for your help.
I’ll keep you informed of my investigation in this thread.
Problem appears to be solved on native compilation .
But it is still present in our Jenkins environment.
I easily obtained same behaviour when I cross-compile on my VM.
For each file analysed, we have following error :
16:29:38.280 INFO: [pool-4-thread-1] /home/stanislas/workspace/embedded/bgm/src/main.cpp
16:29:39.867 ERROR: [pool-4-thread-1] /opt/target_sysroot/usr/include/c++/7.3.0/cstdlib:75 'stdlib.h' file not found
When I look a little up, I see that the compiler probing returns the following list of directories #include “…” search starts here: #include <…> search starts here:
/opt/target/sysroots/corei7-64-cube-linux/usr/include/c++/7.3.0
/opt/target/sysroots/corei7-64-cube-linux/usr/include/c++/7.3.0/x86_64-cube-linux
/opt/target/sysroots/corei7-64-cube-linux/usr/include/c++/7.3.0/backward
/opt/target/sysroots/x86_64-cubesdk-linux/usr/lib/x86_64-cube-linux/gcc/x86_64-cube-linux/7.3.0/include
/opt/target/sysroots/corei7-64-cube-linux/usr/lib/gcc/x86_64-cube-linux/7.3.0/include
/opt/target/sysroots/x86_64-cubesdk-linux/usr/lib/x86_64-cube-linux/gcc/x86_64-cube-linux/7.3.0/include-fixed
/opt/target/sysroots/corei7-64-cube-linux/usr/include/
End of search list.
stdlib.h is present in /opt/target/sysroots/corei7-64-cube-linux/usr/include/
But each file is compiled with following include directives
CXX_INCLUDES = -I /opt/target/sysroots/corei7-64-cube-linux/usr/include/process-template -I /opt/target/sysroots/corei7-64-cube-linux/usr/include/proto-messages -I /opt/target/sysroots/corei7-64-cube-linux/usr/include/
And when I manually modify cmake generated file (flags.cmake) to remove last “-I” part, file is found and analysis is “correct” as in native compilation.
Any idea ?
Again, this behaviour is new for us since with previous version of plugin, there was no such problems… and analysis went just fine.
It’s not easy to follow this from a distance, with no possibility of looking what file is where, but let’s try… stdlib.h is included in /opt/target_sysroot/usr/include/c++/7.3.0/cstdlib. Could you tell if it’s included with <...> or with "..."?
What I don’t really understand is that the folder that contains this cstdlib does not seem to be in your include paths. So it means that some logical steps are missing here. Could you please send us the logs and the build wrapper files of this execution so that we may have a better understanding? Could you also tell us the chain of includes that goes from main.cpp to cstdlib?
Sorry if my previous request has been unclear, but in addition to the build wrapper, we also need the analysis logs (more than just the extract that you shared with us) to confirm what we suspect…
The issue is coming from the fact that you have the same folders set both as system include path and as normal include path:
The compiler probe tells for instance that /opt/target/sysroots/corei7-64-cube-linux/usr/include/ is a system folder (line 694 of sonar_log.txt)
In the build-wrapper.json file, this folder is included through -I /opt/target/sysroots/corei7-64-cube-linux/usr/include/ (line 34).
When this duplication happens, the compiler detects it, and just ignore the -I, while we don’t, and we then have a different behaviour.
Once again, this handling of include path was already present in the previous version of the plug-in, but at that time, we were more resilient to bad configuration (and less accurate too…). I’m reasonably sure that if you look in old log files, you will see some messages about missing stdlib.h.
What can you do?
First, if you explicitly set the -I with those system paths on purpose, you can stop doing this: it’s already set by the --sysroot=/opt/target/sysroots/corei7-64-cube-linux option that you already use.
If you don’t control it directly, maybe you can automate it’s removal? (for instance, the thing you describe about modifying a cmake file)?
I created an jira ticket to correct this behaviour
Great that you found the reason of this problem.
As you said, we don’t control this -I directly, it is imported from an external library…
I can try to temporary patch our Jenkins build in order to modify generated CMake files but it would be better if the plugin’s behaviour was the same as the compiler
I looked a little at old analysis and since -X was not activated, there is no trace of missing file…
Anyway, thanks a lot for your help, the situation is now clearer and we can do something to obtain complete analysis.
I finally found the guilty files : external libraries CMakeLists.txt were a little too inclusive, adding -I clause to */usr/include where it was not “necessary”.
and I failed…
