GC overhead limit exceeded using the VSTS task

SonarCloud
,
1

Hi,

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: SonarQube java.lang.OutOfMemoryError: GC overhead limit exceeded - Stack Overflow

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

thanks,

Greg

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.

3

Hi,

The task looks like this:

- task: SonarSource.sonarcloud.14d9cde6-c1da-4d55-aa01-2965cd301255.SonarCloudPrepare@1
  displayName: Prepare analysis on SonarCloud
  inputs:
    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:
     sonar.exclusions=**/bower_components/**/*,**/node_modules/**/*,**/Scripts/lib/**/*,**/bundle.js
     sonar.web.javaOpts=-Xmx2048m

On the last line, I have tried:

sonar.ce.javaOpts=-Xmx2048m
SONAR_SCANNER_OPTS=-Xmx2048m

But nothing works.

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.

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)

1 Like
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
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?

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?

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 [Deprecated] Suggest new features out of this, to keep it distinct from the initially memory-focused discussion in this topic, and track it from there).

11

Hi,

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

thanks,

Greg

12

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

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.

14

Hi,

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

Thanks

15

Hi,

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

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

thanks,

Greg

16

Hi,

Here are the logs:

https://1drv.ms/u/s!AtMMegtv-j6Jicg0rL8jIefJk15hqg

thanks,

Greg

17

Hi - Any news on this?

18

Any news? I am blocked by this.

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
1 Like
21

I’m blocked by this. Would be nice to see a fix soon

22

Hi,

A newest version of the extension has been deployed (1.8.0). We moved the generated report-task.txt files into another folder, meaning that this problem should not occur anymore.

Mickaël