Scanner Bullseye odd error

sonarcfamily

(Chris Cralle) #1

Hello,
SonarQube Scanner 3.3.0.1492
Java 1.8.0_121 Oracle Corporation (64-bit)
Linux 3.10.0-693.11.6.el7.x86_64 amd64

We recently upgrade SQ from 6.7.6 to 7.6 and this one problem I can not find any reference or clues how to resolve.
This is a C++ project being scanned with SonarQube Scanner for Jenkins 2.8.1

Everything looks fine until near the end and we get this message from debug

DEBUG: Probing compiler: [/opt/BullseyeCoverage/bin/covc, -x, c++, --std, gnu++1z, -v, -dM, -E, -]
DEBUG: stdout:
BullseyeCoverage Compile C++ 8.14.4 Linux-x64
error: unknown option "-x"

java.lang.NullPointerException
	at com.sonar.cpp.N.H.B(na:1388)
	at com.sonar.cpp.N.A.A(na:400)
	at com.sonar.cpp.plugin.R.A(na:2887)
	at com.sonar.cpp.plugin.R.execute(na:156)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
	at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:82)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
	at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:408)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:403)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:360)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:126)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:73)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at com.sun.proxy.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:185)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:137)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:111)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
	at org.sonarsource.scanner.cli.Main.main(Main.java:61)

Has anyone seen a message like or can offer any tips? Thank you very much.


(Chris Cralle) #2

I found the problem. It was the order of elements in my PATH.
Bullseye/bin was up front, and real compilers were all behind. I moved bullseye to the rear, and now sonar is finding the true compiler (g++) correctly.

Thanks the gods… /facepalm


(Chris Cralle) #3

It turns out this is not a solution. With bullseye at the back of the path, the coverage files are not created.
I think this is an issue with build-wrapper remember the symlinks that bulleyes creates when calling cov01 and then when it analyzes the bw-output, instead of following that to g++ it’s using covc instead.


(Massimo Paladin) #4

Hi @ChrisC,

could you please give us a bit more information?

  • version of bullseye
  • sonar-scanner output log
  • build-wrapper.log
  • build-wrapper-dump.json

(Chris Cralle) #5

Hi @mpaladin,
I’ve tried several ways with different versions. The only pieces I have not rolled back on are the sonarserver and cfamily plugin. Going back on scanner, build-wrapper, or sonar jenkins plugin, did not change the behavior.
Sonarqube Server 6.7.1 LTS
Sonarqube Server Dev 7.6

SonarQube Scanner for Jenkins 2.6.1
SonarQube Scanner for Jenkins 2.8.1

build-wrapper 5.1
build-wrapper 6.0

SonarQube Scanner 3.0.3.778
SonarQube Scanner 3.3.0.1492

BullseyeCoverage Compile C++ 8.14.4 Linux-x64

Here the summary of actions being done.
Broken Build Once –
devtoolset-7/enable
Set PATH with Bullseye
cov01 -1
build-wrapper-linux-x86-64 --out-dir ${WORKSPACE}/bw-output make -j
covxml --file $COVFILE --output bsout-cov.xml
Unset Bullseye in PATH
Execute Sonar Plugin

DEBUG: Probing compiler: [/opt/BullseyeCoverage/bin/covc, -x, c++, --std, gnu++1z, -v, -dM, -E, -]
BullseyeCoverage Compile C++ 8.14.4 Linux-x64
error: unknown option “-x”

Have to Build Twice –
devtoolset-7/enable
Set PATH with Bullseye
cov01 -1
make -j
covxml --file COVFILE --output bsout-cov.xml Unset Bullseye in PATH build-wrapper-linux-x86-64 --out-dir {WORKSPACE}/bw-output make -j
Execute Sonar Plugin

Probing compiler: [/opt/rh/devtoolset-7/root/usr/bin/g++, -x, c++, --std, gnu++1z, -v, -dM, -E, -]

What appears to be happening is, for Bullseye to work, it must be pathed in front, so that this link takes effect
/opt/BullseyeCoverage/bin/g++ -> covc

Somewhere, sonar is now saving this variable and using it instead of finding the real g++ in path. I think. I’ll try to get those logs file you ask for. They probably need to be scrubbed before I can share.
Thanks,


(Massimo Paladin) #6

Hi @ChrisC,

I believe you are affected by CPP-1853. In order to confirm that could you please share with me the build-wrapper.log and build-wrapper-dump.json files?


(Chris Cralle) #7

Hi,
The build-wrapper log and json are quite large, and contain much internal information. Is there something I can look for in particular?


(Massimo Paladin) #8

Hi @ChrisC,

you can compress them and share them with me privately.