Gradle
  1. Gradle
  2. GRADLE-1496

sonar task fails with java.lang.OutOfMemoryError: PermGen space

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Resolution: Fixed
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: 1.0-milestone-8

      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" }

      }
      }

        Activity

        Hide
        Peter Niederwieser
        added a comment -

        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.

        Show
        Peter Niederwieser
        added a comment - 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.
        Hide
        Kelly Robinson
        added a comment -

        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

        Show
        Kelly Robinson
        added a comment - 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
        Hide
        Peter Niederwieser
        added a comment -

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

        Show
        Peter Niederwieser
        added a comment - Recent versions of the plugin need considerably less memory when analyzing multi-project builds.

          People

          • Assignee:
            Unassigned
            Reporter:
            Joern Huxhorn
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: