Frequent build-wrapper error: Cannot open logfile: build-wrapper\build-wrapper.log

SonarQube Server / Community Build
, ,
1

Hello,

We have a Jenkins Server in which we are trying to integrate the SonarQube C/C++ branch analysis. We’re working with git in a branchng workflow where every branch start from develop and is merged back to develop when it’s ready and if it has the required quality.

Our problem is that the build-wrapper step of the SonarQube analysis often fails with the following error message:

Cannot open logfile: build-wrapper\build-wrapper.log

This happens almost 4 times out of 5 during the build. It doesn’t happen at the beginning or end of the build, instead it happens randomly in the middle, i.e. not always when building the same file.

After that, when sonar-scanner is executed, it ends up with the following enormous error:

INFO: Using build-wrapper output: d:\ws\hotfix_sonar-develop-update-6EFFI6EAVNTMTYZS2RYRCTG3FENF2GBSVT7NNREKARLBKKRZ6LFA@2\Project\Build\build-wrapper\build-wrapper-dump.json
INFO: 9 compilation units analyzed
INFO: 20 compilation units analyzed
INFO: 34 compilation units analyzed
INFO: 46 compilation units analyzed
INFO: 49 compilation units analyzed
INFO: PCH: 0 + 0 + 0 , 6323 - 0 - 0 - 0
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 52.095s
INFO: Final Memory: 57M/1050M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarQube Scanner execution
java.lang.RuntimeException: java.io.EOFException: End of input at line 14426 column 28
	at com.A.B.B.K.C(na:62)
	at com.sonar.cpp.driver.I.A(na:673)
	at com.sonar.cpp.plugin.B.A(na:289)
	at com.sonar.cpp.plugin.Q.A(na:1544)
	at com.sonar.cpp.plugin.Q.execute(na:292)
	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:180)
	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:302)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:297)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:271)
	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.executeTask(Batch.java:111)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
	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:233)
	at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
	at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:77)
	at org.sonarsource.scanner.cli.Main.main(Main.java:61)
Caused by: java.io.EOFException: End of input at line 14426 column 28
	at com.A.A.D.E.B(na:3385)
	at com.A.A.D.E.E(na:2192)
	at com.A.A.D.E.A(na:294)
	at com.sonar.cpp.driver.I.A(na:850)
	at com.sonar.cpp.driver.I.A(na:3302)
	... 35 more

ERROR: 
ERROR: Re-run SonarQube Scanner using the -X switch to enable full debug logging.
script returned exit code 1

I guess the sonar-scanner error comes from an incomplete build-wrapper-dump.json file, due to the first error. However I cannot understand why the build-wrapper step fails.

Our sonar-project.properties looks like this:

# unique project identifier (required)
sonar.projectKey=PROJECT

# project metadata (used to be required, optional since SonarQube 6.1)
sonar.projectName=PROJECT
sonar.projectVersion=1.0
sonar.cfamily.build-wrapper-output=Project\\Build\\build-wrapper
sonar.sourceEncoding=UTF-8

# path to source directories (required)
sonar.sources=SourceCode\\
sonar.exclusions=SourceCode\\External\\**

# variable options
sonar.branch.target=develop

And the part of the JenkinsFile which starts the analysis is this one:

                stage('SonarQube analysis') {
                    steps {
                        dir ('Project\\Build') {
                            script{
                                try{
                                    bat 'C:/sonar/build-wrapper-win-x86/build-wrapper-win-x86-64.exe --out-dir build-wrapper make -r all'
                                }
                                catch (Exception e) {}
                            }
                        }
                        script {
                            scannerHome = tool 'SonarQube Scanner V3.0.3.778'
                        }
                        withSonarQubeEnv('SonarQube') {
                            bat "${scannerHome}/bin/sonar-scanner -Dsonar.branch.name=${env.BRANCH_NAME}"
                        }
                        timeout(time: 1, unit: 'HOURS') {
                            waitForQualityGate abortPipeline: true
                        }
                    }

Can someone help me understand why the build-wrapper sometimes fails with this error ? What I don’t get is why it works from time to time, but fails most of the time.

Environment

SonarQube 71 (build 11001)
Build done with GNU make through a Makefile, calling arm-none-eabi-gcc (~200 files to build)
Runs on Windows Server 2012

Thank you for any help you can provide

1 Like
2

It’s hard to guess what might happen, but I’m wondering if this could be a network issue. Is this build-wrapper\build-wrapper.log file on a local drive for the build machine? Is it on the same drive where all the build output are generated?

Another possibility would be that another process tries to open that log file, thus being in conflict (maybe a generic process that scans logs for errors? Or an antivirus program?)…

Maybe this can be checked. If you look at that file, is this a correct json file, with all tags closed?

1 Like
3

Thank you for your reply. Everything is built locally so I doubt it’s a network issue, however the antivirus hypothesis makes sense and there is indeed one running on this server, so I will have a closer look at it.

Regarding the .json files, when the analysis fails this file seems incomplete and the last line looks like this:

"WORKSPACE_ROOT=d:\\ws\\"]}

So at least we’re now sure that the failing step is the build-wrapper, not the scanner.

Do you know if there is a way to obtain more information from build-wrapper about what exactly prevents it from accessing the log file ?

1 Like
4

Hello Timothée,

You cannot get more information from the build wrapper itself, but if just deactivating the antivirus software does not work, there is a way to monitor all that happens to this file. However I must warn you that it’s a little bit cumbersome, like using a Panzer to crack open a nut…

You seem to be on Windows, so you can download the free utility Process Monitor. This will allow you to monitor all accesses to the files you are interested in (you should set-up some filters in the tool to only record what happens to the build-wrapper.log and build-wrapper-dump.json files, otherwise you will be overwhelmed by useless messages). From the recorded log file, you should then be able to see if it contains some errors, and around those errors if some processes other than the build wrapper tried to access the files.

Hope you’ll find what happens!

3 Likes
5

Hello Loïc,

By using Process Monitor we’ve been able to confirm your theory, the antivirus is indeed accessing the log file all the time during the build. We’ll see if disabling it totally solves the problem, and in such case I’ll accept your answer :slight_smile:

Thank you for your help and answers.

Edit: Disabling the antivirus analysis on the build folder solved the issue :slight_smile:

1 Like