4

I am using Sonar Runner 2.2 and set SONAR_RUNNER_OPTS=-Xmx8000m, but I am getting the following error:

Final Memory: 17M/5389M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Java heap space

How can this be?

Marco Eckstein
  • 4,448
  • 4
  • 37
  • 48

3 Answers3

2

I had the same problem and found a very different solution, perhaps because I don't believe any of the previous answers / comments. With 10 million lines of code (that's more code than is in an F16 fighter jet), if you have a 100 characters per line (a crazy size), you could load the whole code base into 1GB of memory. Simple math. Why would 8GB of memory fail?

Answer: Because the community Sonar C++ scanner seems to have a bug where it picks up ANY file with the letter 'c' in it's extension. That includes .doc, .docx, .ipch, etc. Hence, the reason it's running out of memory is because it's trying to read some file that it thinks is 300mb of pure code but really it should be ignored.

Solution: Find the extensions used by all of the files in your project (see here).

Then add these other extensions as exclusions in your sonar.properties file:

sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch

Then set your memory limits back to regular amounts:

%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
Community
  • 1
  • 1
Ryan Shillington
  • 23,006
  • 14
  • 93
  • 108
1

If you allow the heap space to grow up to 8000m, this does not mean that you will always have enough physical memory to get there as you have other processes running on your operating system that also consume memory. For instance, if you have "only" 8GB of RAM on your machine, it's likely that the heap space will never be able to reach the maximum you've set.

BTW, I don't know what you're trying to analyse but I've never seen anyone requiring so much memory to analyse a project.

Fabrice - SonarSource Team
  • 26,535
  • 3
  • 62
  • 58
  • The machine has 24GB RAM. The project has more than 80k LOC and many violations. I'll try again with sonar.findbugs.effort less than Max. – Marco Eckstein Jun 24 '13 at 10:48
  • What you can do also is to use a lighter quality profile to begin with. Running an analysis with all available rules obvisously consumes more memory - and it won't help you more as digging in the results will be very difficult. – Fabrice - SonarSource Team Jun 25 '13 at 07:59
  • FYI, with Sonar 3.6 this memory hotspot when having millions of issues have been mainly solved: http://jira.codehaus.org/browse/SONAR-4360. – Freddy - SonarSource Team Jun 26 '13 at 20:32
  • But with a paging file of say, 4GB, while it would take a long time because of paging, it should still work. – Ryan Shillington Dec 09 '13 at 22:01
0

I faced the same problem while running test cases. With the help of Visuval VM, analysed the min and max memory allocating to PermGen during test cases execution and found that, its allocating 80MB to PermGen. Hence the same can be managed through pom.xml in properties section as follows.

<properties>
    <argLine>-XX:PermSize=256m -XX:MaxPermSize=256m</argLine>
</properties>

This <argLine> tag, we can use either in <maven-surefire-plugin> or in <properties>. The advantage of using in section is, the same configuration can be utilized by both test cases and sonar. Please find reference here.

Paramesh Korrakuti
  • 1,997
  • 4
  • 27
  • 39