GC overhead limit exceeded using the VSTS task


(Greg Pakes) #1


I am using the VSTS tasks and am getting the error “GC overhead limit exceeded”. I can’t see how to pass into the VSTS task the memory settings as specified here: https://stackoverflow.com/questions/39114020/sonarqube-java-lang-outofmemoryerror-gc-overhead-limit-exceeded

I am trying to use the “extraProperties” of the task, but I always see the following in the logs:

SONAR_SCANNER_OPTS is not configured. Setting it to the default value of -Xmx1024m



(Nicolas Bontoux) #2

Hey Greg,

Can you share what exactly you’ve tried so far ? (which task, which property, which value)

Impromptu thought: I guess VSTS (or Azure DevOps should I say now) provides a way to set environment variables for the build execution, in which case you could try passing SONAR_SCANNER_OPTS there.

(Greg Pakes) #3


The task looks like this:

- task: SonarSource.sonarcloud.14d9cde6-c1da-4d55-aa01-2965cd301255.SonarCloudPrepare@1
  displayName: Prepare analysis on SonarCloud
    SonarCloud: SonarCloud
    organization: xxxx
    projectKey: xxxx
    projectName: xxxx
    projectVersion: '$(Build.BuildNumber)'
    extraProperties: |
     # Additional properties that will be passed to the scanner, 
     # Put one key=value per line, example:

On the last line, I have tried:


But nothing works.

(Dinesh Bolkensteyn) #5

Could you try to give more memory to the Run Code Analysis task rather than the Prepare analysis on SonarCloud one?

Also, it would be helpful if you could share the last few lines of the build logs for us to know at which phase of the analysis the out of memory is being reached.

(Dinesh Bolkensteyn) #6

Also both sonar.web.javaOpts and sonar.ce.javaOpts are server-side options for SonarQube operation. You do not need to worry about those as you are relying on SonarCloud. Setting those for an analysis during a build will have no effect. Just set SONAR_SCANNER_OPTS which as you saw in your deleted post does have an effect (i.e. setting it to 4096 bytes did lead to an immediate failure of the JVM)

(Greg Pakes) #7

Thanks - I have managed to get this to work using your advice. I have set a variable in the VSTS build called SONAR_SCANNER_OPTS with a value of -Xmx8192m.

This now allows the Run Code Analysis task to pass.

The issue now is that the Publish Quality Gate Result task now fails with:

2018-09-17T03:41:36.9100259Z ##[section]Starting: Publish Quality Gate Result
2018-09-17T03:41:36.9103130Z ==============================================================================
2018-09-17T03:41:36.9103266Z Task         : Publish Quality Gate Result
2018-09-17T03:41:36.9103412Z Description  : Publish SonarCloud's Quality Gate result on the VSTS/TFS build result, to be used after the actual analysis.
2018-09-17T03:41:36.9103543Z Version      : 1.3.0
2018-09-17T03:41:36.9103640Z Author       : sonarsource
2018-09-17T03:41:36.9103874Z Help         : [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
2018-09-17T03:41:36.9104028Z ==============================================================================
2018-09-17T03:41:43.0254685Z ##[error]Failed find: Maximum call stack size exceeded
2018-09-17T03:41:43.1234051Z ##[section]Finishing: Publish Quality Gate Result

(Greg Pakes) #8

I think this is to do with the following error in the Background Tasks:

This analysis will make your organization 'xxx' to reach the maximum allowed lines limit. 
Please contact the administrator of the organization to resolve this issue.

The issue is that it doesn’t say what I need to bump it up to. I have already bumped it up to 1m lines of code and I am still getting the error. Is it just a case of continually bumping it, until it succeeds?

(Dinesh Bolkensteyn) #9

I’m glad your initial problem regarding the GC overhead limit is solved @gregpakes.

Now I indeed see 2 things to be improved:

  1. The error message ##[error]Failed find: Maximum call stack size exceeded in the publish analysis results task is not user-friendly
  2. The background task failure could mention how many LOC it would require at least in order to succeed

@NicoB What is your feeling on this?

(Nicolas Bontoux) #10

Well the Maximum call stack size exceeded seems like a bug to me, would be interesting to know conditions that reproduce it (isn’t directly tied to Background Task error imo).

And regarding the LOC threshold:

I feel like this needs to be thought through first, too early to jump to solutions right now. ^^ My reasoning: the amount of LOC purchased (and therefore the $$ paid) could be considered a private matter by the org admin, one which the org admin might not necessarily want all project admins to be aware of.

All in all am not saying the current message is ideal (understand the unclarity @gregpakes, and indeed right now you’ll have to iterate gradually), however I would suggest we just track it from there and discuss the appropriate solution ad-hoc. @Fabrice_Bellingard: sounds fair to you ? (@gregpakes: am also thinking that it might be worth for you to make a dedicated #suggestions out of this, to keep it distinct from the initially memory-focused discussion in this topic, and track it from there).

(Greg Pakes) #11


So what do you need to know regarding the Maximum call stack size exceeded issue?



(Greg Pakes) #12

Any news on this? My builds are still failing due to this error?

(Fabrice Bellingard) #13

Hi Greg,

Please contact us on https://sonarcloud.io/about/contact so that you can share the details of your private plan. I will then take a look at the current state of your organization, and if it’s “just” a matter of increasing the number of lines of code for your org, I will guide you on how to make your analyses succeed.

(Julien Henry) #14


Could you please run your build with debug variable set to true, so that we have more logs?


(Greg Pakes) #15


It’s not the LOC issue - I have got past that now.

I will send through the debug logs. They are big!



(Greg Pakes) #16


Here are the logs:




(Greg Pakes) #17

Hi - Any news on this?

(Greg Pakes) #18

Any news? I am blocked by this.

(Julien Henry) #20

Hi @gregpakes and sorry for the late reply.

The issue is caused by the fact there are too many files in the workspace after the build + analysis, and the find utility we are using seems to be badly implemented.

I have created a ticket to fix the problem during the next sprint: https://jira.sonarsource.com/browse/VSTS-172

In the meantime, as a workaround, you can add a powershell task just before the “publish quality gate results” task and do some cleanup to limit the number of files. Something like:

Get-ChildItem $Agent.BuildDirectory -Recurse | Where{$_.Name -Match ".*css-bundle"} | Remove-Item