Rules not triggered apart from Duplications

Hello together,

I have used the trial version of the SonarQube Developer Edition to execute the SonarScanner on a project mainly written in the programming language C. When installing SonarQube I followed all instructions about the SonarCFamily (including the build-wrapper), but when executing the scanner, I would have expected more rules to be violated by the code.

Specifically speaking: a comparable static code analysis tool executed on the same code detected defects which I thought were represented by the SonarQube set of rules for the language C, but the Scanner did only show me “duplicate lines of code”-notifications.

My question is: if only “duplicate lines of code”-notifications are thrown, could there be a configuration problem with my SonarQube instance? I assumed that all rules of the specific language are checked when executing the scanner, so the other explanation would be that the rules are simply triggered differently.

I would be very thankful for your assistance.

Kind regards,
Julian Frattini

Hi @JulianFrattini,

Yes, it is likely to be a configuration issue. I would encourage you to update the SonarCFamily analyzer to version 6.4, we added some checks to inform the user when this kind of configuration issue happens. From there and looking at logs and configuration it should be able to see where the problem is.

2 Likes

Hello @mpaladin,

While actualizing all software components of SonarQube and resetting our evaluation environment, the root of this problem was seemingly identified but another problem sparked.

The problem probably was that the build-wrapper was not correctly set up.

However: attempting to now execute the build-wrapper accordingly, we encountered a new problem. Projects are not built by a simple makefile in the evaluated environment, but by a custom Shell-Script: this takes a target-file into consideration, which contains information e.g. about specific compilers, and then builds the project accordingly. However, this custom script is not accepted by the build-wrapper and yields the error-message
[SONARSOURCE BUILD_WRAPPER] failed to execute path/to/script/script: %1 is not a valid Win32 application.

What are the restrictions for build processes to be accepted by the build-wrapper? Is there any way to execute the build-wrapper, when no simple makefile exists?

Kind regards,
Julian Frattini

Hi @JulianFrattini,

can you give the real example?

My guess is that you just need to do something like:

build-wrapper-win --out-dir cfam-out bash script.sh

note the bash.

1 Like

Hello @mpaladin,

Thanks for the hint with “bash”. Now the build-wrapper is not complaining.

However: For how long should the execution of the build-wrapper take? The build process would take a few minutes itself, but when executing the build-wrapper I did not get a result even after several hours. I can only identify that a “build-wrapper.txt” and “build-wrapper-dump.json” file have been created in my cfam-out directory, but there is no further console output in order to track the process. Is there any way to verify that the build-wrapper is working?

Edit: When terminating the execution and restarting it, the message “Cannot open logfile: cfam-out\build-wrapper.log” occurs. So something seems to be happening, but I cannot validate what exactly.

Hi @JulianFrattini,

build-wrapper should not impact build time, so something wrong is happening. What version of build-wrapper are you using? Can you make sure you are using build-wrapper version 6.4?

Hello @mpaladin,

Yes, I do use version 6.4 of the build-wrapper.

I have attempted to trace the build-wrappers access to files via Process Monitor for Windows, which reveals that once the build-wrapper is started, some process tries to find a file wc.db in a sub directory .svn, which cannot be found. Is this related to the build-wrapper and does that mean, that the build-wrapper has to be executed at a specific directory location?

And does the build-wrapper provide any form of output, where I could trace its process internally?

Hi @JulianFrattini,

no, no need to execute it at a specific location.

Yes, the build-wrapper.log contains some information, would you be able to share this file?

Hello @mpaladin

Yes, I can do that. Would it be possible to get in direct contact to you? I would rather avoid publicly posting the logfile.

Hi @JulianFrattini,

I sent you a PM where you can share privately.

1 Like

Hi @JulianFrattini,

for the records, I created CPP-2359 to exclude tcc.exe to be recognized as compiler.

1 Like