Dear all,
After moving sonarqube to a windows 2016 server I get a crash when uploading data. My old server was a linux server and the only thing I changed was the server. Uploading the data to the linux is still fine, changing to the Windows Server crashes.
My Windows Server setup:
Windows Server 2016
SonarQube 6.7.6 LTS, 64Bit
PostgeSQL 10.6 database
JDK 1.8.192
My Client setup:
Windows 10, 64Bit
Scanner is 3.2.0.1227
Below is the short version of the log. At line “11:59:39.486 ERROR: Exception in thread pool-3-thread-1” I get a Windows window “subprocess.exe is no longer working”
For analysing the problem I also installed a community version without C/C++ parser. Using this version I can upload the data. I only get the crash with an installed developer version.
11:59:25.060 INFO: Scanner configuration file: NONE
11:59:25.067 INFO: Project root configuration file: D:\_Projects\Noscere\trunk\02_SW\DoorApplication\02_WinDev\sonar-project.properties
11:59:25.084 INFO: SonarQube Scanner 3.2.0.1227
11:59:25.084 INFO: Java 1.8.0_192 Oracle Corporation (64-bit)
11:59:25.084 INFO: Windows 10 10.0 amd64
11:59:25.217 DEBUG: keyStore is :
11:59:25.217 DEBUG: keyStore type is : jks
11:59:25.217 DEBUG: keyStore provider is :
11:59:25.218 DEBUG: init keystore
....
#define __ATOMIC_RELEASE 3
#define __declspec(x) __attribute__((x))
11:59:34.216 DEBUG: stderr:
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\g++.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32 --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --with-tune=generic --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-dM' '-E' '-shared-libgcc' '-mtune=generic' '-march=i586'
c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/cc1plus.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/6.3.0/ - -mtune=generic -march=i586 -std=c++11 -dM
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++/mingw32"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++/backward"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include"
ignoring nonexistent directory "/mingw/include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include-fixed"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/mingw32
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/backward
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include-fixed
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../mingw32/include
End of search list.
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/6.3.0/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-dM' '-E' '-shared-libgcc' '-mtune=generic' '-march=i586'
11:59:34.226 INFO: [pool-3-thread-1] D:/_Projects/Noscere/trunk/02_SW/DoorApplication/02_WinDev/Debug/../../01_Source/Framework/Learner/DoorLearnerController.cpp
11:59:39.486 ERROR: Exception in thread pool-3-thread-1
java.lang.IllegalStateException: exit code != 0
at com.sonar.cpp.N.E.A(na:869)
at com.sonar.cpp.N.E.A(na:444)
at com.sonar.cpp.plugin.R.A(na:2250)
at com.sonar.cpp.N.F.B(na:50)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
11:59:39.619 INFO: ------------------------------------------------------------------------
11:59:39.619 INFO: EXECUTION FAILURE
11:59:39.620 INFO: ------------------------------------------------------------------------
11:59:39.621 INFO: Total time: 14.581s
11:59:39.721 INFO: Final Memory: 31M/426M
11:59:39.721 INFO: ------------------------------------------------------------------------
11:59:39.722 ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: java.lang.IllegalStateException: exit code != 0
at com.sonar.cpp.N.F.A(na:1714)
at com.sonar.cpp.plugin.R.B(na:3237)
at com.sonar.cpp.plugin.R.A(na:1306)
at com.sonar.cpp.plugin.R.execute(na:156)
at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)
at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:73)
at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:177)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:291)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:286)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:264)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:71)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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:171)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:128)
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)
Caused by: java.lang.IllegalStateException: exit code != 0
at com.sonar.cpp.N.E.A(na:869)
at com.sonar.cpp.N.E.A(na:444)
at com.sonar.cpp.plugin.R.A(na:2250)
at com.sonar.cpp.N.F.B(na:50)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Please provide the version of your SonarCFamily analyzer. You can find it in Administration > Marketplace
Also, it’s not clear to me whether the change you made was to move analysis to a Windows box, or SonarQube itself. I’m guessing the former since it looks like you’re using MinGW in your build to replicate the lost Linux environment.
Hi Ann,
The SonarCFamily analyzer is 6.0 (build 10816).
I had a Linux server with SonarQube installed. We change now our server infrastructure to Windows. Now I set up SonarQube on the new Windows Server. MinGW is just the compiler for my windows application.
The only thing I have to change on my Windows Client is in the the sonar-project.properties
sonar.core.serverBaseURL=…
sonar.host.url=…
could you please run the analysis specifying the following property and send me privately the generated file sonar-cfamily.reproducer? The generated file is a self containing reproducer which allow us to debug the failure.
I added the line to sonar-project.properties and got this:
16:17:30.471 INFO: ------------------------------------------------------------------------
16:17:30.471 INFO: EXECUTION FAILURE
16:17:30.472 INFO: ------------------------------------------------------------------------
16:17:30.472 INFO: Total time: 7.165s
16:17:30.577 INFO: Final Memory: 44M/598M
16:17:30.579 INFO: ------------------------------------------------------------------------
16:17:30.580 ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: sonar.cfamily.reproducer
at com.sonar.cpp.plugin.R.execute(na:2041)
at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)
at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:73)
at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:177)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:291)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:286)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:264)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:71)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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:171)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:128)
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)
@Inok then you’re not getting file, because value of property doesn’t match path to any analyzed file, including one that was causing initial error. Either because path is different between executions or was specified incorrectly.
It must match literally character by character, so make sure:
execute analysis without sonar.cfamily.reproducer to get initial failure and exact spelling of path such as
execute analysis in exactly the same environment on exactly the same machine with exactly the same paths and with property sonar.cfamily.reproducer correctly set to a path determined in step 1 such as D:/some/../path/to_file.cpp to get below message and requested file
ERROR: Please contact SonarSource Support and provide file full_path_to/sonar-cfamily.reproducer
I found an interesting behaviour. I copied the source structure into another directory which is not under source control. There I can upload the data to SonarQube. Why this?
I came to this approach during verify uploading to the old server. When I shut down the old server I get an java.lang.IllegalStateException: Error when executing blame for file…
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Authentication required for '<https://xxxxx.com:443>'
Jumping from subject to subject is counterproductive, so please let’s get back to initial subject and focus on the only one problem at a time. Thanks you for your understanding.
Sorry, but maybe you overlooked file the same way as message?
And sorry, but in case of presence of message with path to file, we have no idea how else we can help you to locate it.
Another option will be to to send us minimalistic yet absolutely complete example of project that reproduces initial problem.
In absence of the requested file and without a way to reproduce your problem, there is nothing what/how we can investigate this and IMO the only possible advice - is to start excluding files from analysis one by one to find a subset of files that can be successfully analysed and another subset that fails and can be a base for the requested example.
Well I am searching this file since last friday… As I sayed the focus was the file and not the message.
There is an exception after the message…
But what about my information that I can upload the data when I copy the project to a folder that is not under version control?
I also removed the version control information in this folder and then it works.
For me it seems it has something to do with the new svn server but I don’t understand why the scanner is accessing the svn server at all. I haven’t configured an svn access.
I have no idea how to provide you an example under these circumstances.
I still can’t produce the requested file but I need a solution. So far I checked 2 other projects which I can upload successfully.
I reduced my problematic project to a few classes -> Still the same crash.
When I copy the already compiled source structure into another directory I can upload successfully (already mentioned above). Now I analyzed the differences in the debug log.
Both uploads processes the same code with the same build-wrapper-dump.json from the same compilation. The only difference is the location from where I started the upload.
successful upload:
…
10:37:29.694 DEBUG: Not enough content in ‘01_Source/Properties/Version.subwcrev-template.h’ to have CPD blocks, it will not be part of the duplication detection
10:37:29.759 INFO: 0 compilation units analyzed
10:37:29.759 INFO: Sensor CFamily [cpp] (done) | time=1201ms
10:37:29.760 INFO: Sensor Zero Coverage Sensor
…
upload with crash:
…
10:38:57.039 DEBUG: Not enough content in ‘01_Source/Properties/Version.subwcrev-template.h’ to have CPD blocks, it will not be part of the duplication detection
10:38:57.073 DEBUG: Probing compiler: [C:\MinGW\bin\g++.exe, -x, c++, --std, c++11, -v, -dM, -E, -]
10:38:57.184 DEBUG: stdout: #defineDBL_MIN_EXP (-1021) #define __cpp_attributes 200809 #defineUINT_LEAST16_MAX 0xffff
…
In the failing log I see “Probing compiler: [C:\MinGW\bin\g++.exe, …”
Does somebody know what means “Probing compiler” and why the scanner is doing this?
the best would be to put it in a public repository like GitHub and setup the analysis to run somewhere like AppVeyor in order to reproduce the failure, you could setup the analysis against SonarCloud, our public instance which is free for open source projects.
Hmmm, I don’t think I can reproduce the bug in GitHub and or AppVeyor because the bug is only in context of our new VisualSVN server in combination with MinGW compiler. In the mean time I assume it has something to do with the url. Our last server used the svn protocol, the new VisualSvn uses https. Using the same project with an ARM compiler I get also an upload error but I can eliminate with sonar.scm.disabled=true. With MinGW compiler I get the crash. The project is just a class with “Hello World”. The environment makes the problem.
My workaround at the moment is: After compiling I copy the project in a temporary folder without svn context and upload from this location.
