Latest C/C++ analyses generate false positives

Hi all !

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)

Here are examples for each rules :

Is it normal to already use the 6.0 version of plugin ? since it seems to be still under development (according to the Jira roadmap)

Is there a way to force sonar-scanner (for linux) to use a specific version ?

For your information :

  • OS : Linux Fedora 28
  • SonarScanner : 3.2.0.1227
  • SonarCloud licencing : Paid for 1M LOC

Thx for your replies :slight_smile:

Hello Stan,

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?

Thank you,

Hello Loïc,

Our code is private & copyrighted then I just can’t share it with you.
But I can share the analysis logs, what do you need exactly ?

I upload following files :

  • the file “analysis.log” located in .scannerwork/scanner-report.analysis.log.txt (10.0 KB)
  • the debug trace of scanner execution. scanner.log.txt (59.0 KB)

If you need more information, I will give them to you as possible as I can.

Thx for you help.

Hello Stan,

As you can see in the scanner.log file:

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.

At the same time, I created a ticket to improve this behaviour.

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.

Hello Loïc,

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.

Hello again,

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.

Thx for your help.

Hello again Stan,

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?

Thank you,

Ok my bad… I try to “obfuscate” some part of our paths :wink: and I failed…

cstdlib is located in /opt/target/sysroots/corei7-64-cube-linux/usr/include/c++/7.3.0 which is in my include path.
stdlib.h is included with #include_next <stdlib.h> as you can see here https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/c_global/cstdlib#L75

I’m out of the office now, but I can send you some more logs tomorrow

Hello Loïc,

Here you can find build wrapper outputs :

After a little look-up, cstdlib is not included by one of our sources files :sweat_smile:
Probably a long include chain…

Thx for your help

Hello Stan,

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…

Here they are :wink:

All are coming from the last run, a few minutes ago…
Hope it will help you

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

Hope this helps,

Hello Loïc,

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 :wink:

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.

Have a nice day :wink:

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”.

I corrected them and now everything seems fine. :man_dancing:

Thx for your help.