[GRADLE-1496] sonar task fails with java.lang.OutOfMemoryError: PermGen space Created: 27/Apr/11  Updated: 04/Jan/13  Resolved: 13/Jan/12

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-3
Fix Version/s: 1.0-milestone-8

Type: Bug
Reporter: Joern Huxhorn Assignee: Unassigned
Resolution: Fixed Votes: 0


 Description   

The "sonar" task executing on my project over at https://github.com/huxi/sulky keeps failing with "java.lang.OutOfMemoryError: PermGen space"

I gave this several tries:
a) no manual JAVA_OPTS
b) export JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=128m"
c) export JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=512m"

With increasing amount of MaxPermSize my build got further than before.
I guess that it would probably be able to finish with 1G of PermSize for sulky but this wouldn't be of much use since my other project, "lilith" is much larger.

The stacktrace of the last crash looks like this:
java.lang.OutOfMemoryError: PermGen space
at org.picocontainer.monitors.NullComponentMonitor.lifecycleInvocationFailed(NullComponentMonitor.java:77)
at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.monitorAndThrowReflectionLifecycleException(ReflectionLifecycleStrategy.java:132)
at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.invokeMethod(ReflectionLifecycleStrategy.java:115)
at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.stop(ReflectionLifecycleStrategy.java:96)
at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.stop(AbstractInjectionFactory.java:88)
at org.picocontainer.behaviors.AbstractBehavior.stop(AbstractBehavior.java:179)
at org.picocontainer.behaviors.Stored$RealComponentLifecycle.stop(Stored.java:141)
at org.picocontainer.behaviors.Stored.stop(Stored.java:118)
at org.picocontainer.DefaultPicoContainer.stopAdapters(DefaultPicoContainer.java:1029)
at org.picocontainer.DefaultPicoContainer.stop(DefaultPicoContainer.java:782)
at org.sonar.batch.Batch.execute(Batch.java:70)
at org.sonar.batch.Batch$execute.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
at org.gradle.api.plugins.sonar.internal.SonarCodeAnalyzer.execute(SonarCodeAnalyzer.groovy:52)
at org.gradle.api.plugins.sonar.internal.SonarCodeAnalyzer$execute.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.gradle.api.plugins.sonar.internal.SonarCodeAnalyzer$execute.call(Unknown Source)
at org.gradle.api.plugins.sonar.Sonar$_execute_closure1.doCall(Sonar.groovy:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at org.gradle.api.plugins.sonar.Sonar$_execute_closure1.doCall(Sonar.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
but will likely be of little use, I guess.

I executed my build using './gradlew -I initSonar.gradle sonar' with the init-file looking like this:
projectsEvaluated {
rootProject.subprojects {
apply plugin: 'sonar'
sonar

{ serverUrl = "url" globalProperty "sonar.jdbc.url", "jdbc:mysql://ip:3306/sonar?autoReconnect=true&useUnicode=true&characterEncoding=utf8" globalProperty "sonar.jdbc.driverClassName", "com.mysql.jdbc.Driver" globalProperty "sonar.jdbc.username", "sonar" globalProperty "sonar.jdbc.password", "xxx" }

}
}



 Comments   
Comment by Peter Niederwieser [ 28/Apr/11 ]

What I can say is that I've analyzed the whole Gradle project (Sonar task ran over an hour) with -XX:MaxPermSize=512M or 1G (don't remember). The problem is unlikely in the Gradle-Sonar integration. Instead, either Gradle in general, or the Sonar client libraries, or both of them use (too) much permgen space.

Comment by Kelly Robinson [ 28/Apr/11 ]

I also saw errors regarding -XX:ReservedCodeCacheSize running against about half a million lines of code(spread across 15 modules).
I was able to complete with these settings for JAVA_OPTS(not tuned at all)
-Xmx1024M -XX:MaxPermSize=512M -XX:ReservedCodeCacheSize=512M

Comment by Peter Niederwieser [ 13/Jan/12 ]

Recent versions of the plugin need considerably less memory when analyzing multi-project builds.

Generated at Wed Jun 30 11:56:59 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.