Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1960

OutOfMemoryError from CheckStyle plugin

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: warnings-ng-plugin
    • Labels:
      None
    • Environment:
      Platform: PC, OS: Linux
    • Similar Issues:

      Description

      I have a project that does not have a very large number of CheckStyle issues
      (less than 6500). Building it using Maven on the command line does not have any
      issues. However, when I build it using the Maven runner in Hudson, I get an
      OutOfMemoryError. I have tried using -Xmx768M and -XX:MaxPermSize=256M when I
      start tomcat, but they have not seemed to fix the problem. The stack trace does
      not seem to be the same between runs.

      [INFO] Generating "Checkstyle" report.
      [WARNING] File encoding has not been set, using platform encoding
      ANSI_X3.4-1968, i.e. build is platform dependent!
      [INFO] There are 295 checkstyle errors.

      <snip/>

      [INFO] Generating "Project Team" report.
      [PMD] Successfully parsed file
      /var/lib/hudson/jobs/endx_nightly/workspace/src/endx-webapp/target/pmd.xml of
      module enDx Web App with 235 warnings.
      [PMD] A total of 235 annotations have been found.
      [CHECKSTYLE] Successfully parsed file
      /var/lib/hudson/jobs/endx_nightly/workspace/src/endx-webapp/target/checkstyle-result.xml
      of module enDx Web App with 6293 warnings.
      [HUDSON] Archiving
      /var/lib/hudson/jobs/endx_nightly/workspace/src/endx-webapp/pom.xml to <snip/>
      [HUDSON] Archiving
      /var/lib/hudson/jobs/endx_nightly/workspace/src/endx-webapp/target/endx-webapp.war
      to <snip/>
      [INFO] ------------------------------------------------------------------------
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Java heap space
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      java.lang.OutOfMemoryError: Java heap space
      at java.util.HashSet.<init>(HashSet.java:86)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addType(AnnotationContainer.java:205)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.updateMappings(AnnotationContainer.java:167)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addAnnotation(AnnotationContainer.java:262)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addFile(AnnotationContainer.java:252)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.updateMappings(AnnotationContainer.java:176)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addAnnotation(AnnotationContainer.java:262)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addModule(AnnotationContainer.java:222)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.updateMappings(AnnotationContainer.java:170)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addAnnotation(AnnotationContainer.java:262)
      at
      hudson.plugins.checkstyle.util.model.AnnotationContainer.addAnnotations(AnnotationContainer.java:272)
      at hudson.plugins.checkstyle.util.model.JavaProject.addModule(JavaProject.java:46)
      at hudson.plugins.checkstyle.util.FilesParser.invoke(FilesParser.java:94)
      at hudson.plugins.checkstyle.util.FilesParser.invoke(FilesParser.java:22)
      at hudson.FilePath.act(FilePath.java:315)
      at hudson.plugins.checkstyle.CheckStyleReporter.perform(CheckStyleReporter.java:65)
      at
      hudson.plugins.checkstyle.util.HealthAwareMavenReporter.postExecute(HealthAwareMavenReporter.java:125)
      at
      hudson.maven.MavenModuleSetBuild$Builder.postExecute(MavenModuleSetBuild.java:585)
      at hudson.maven.MavenBuilder$Adapter.postExecute(MavenBuilder.java:250)
      at
      hudson.maven.agent.PluginManagerInterceptor$1MojoConfig.callPost(PluginManagerInterceptor.java:104)
      at
      hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:137)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
      at
      org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
      at
      org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:42)
      at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
      at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
      at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        Attachments

          Issue Links

            Activity

            Hide
            drulli Ulli Hafner added a comment -

            Well, actually I think it would be far more efficient if the serialization would not be in XML. That would not only reduce the parsing times it also would significantly reduce the file I/O. Additionaly, reading all of the warnings is also not required for the typical use cases (see JENKINS-2320).

            However, I don't see a simple way to change the current behavior since the plug-in was designed to show a couple of warnings only. So don't expect a solution in the near future.

            Show
            drulli Ulli Hafner added a comment - Well, actually I think it would be far more efficient if the serialization would not be in XML. That would not only reduce the parsing times it also would significantly reduce the file I/O. Additionaly, reading all of the warnings is also not required for the typical use cases (see JENKINS-2320 ). However, I don't see a simple way to change the current behavior since the plug-in was designed to show a couple of warnings only. So don't expect a solution in the near future.
            Hide
            weigo weigo added a comment -

            Do you have something specific in mind regarding the serialization?

            It would probably make sense to change to something that lets you query
            subsets of warnings without loading all warnings into memory.

            Show
            weigo weigo added a comment - Do you have something specific in mind regarding the serialization? It would probably make sense to change to something that lets you query subsets of warnings without loading all warnings into memory.
            Hide
            drulli Ulli Hafner added a comment -

            I thought about using a database to store the warnings, but that involves a lot of work...

            Show
            drulli Ulli Hafner added a comment - I thought about using a database to store the warnings, but that involves a lot of work...
            Hide
            weigo weigo added a comment -

            Would you care to outline a roadmap?

            My understanding of the affected plugins is very limited
            so my view of the problems is rather narrow.

            I think extracting an interface for supplying the relevant
            data could be the first step.

            This would encapsulate how a plugin provides its data (in
            form of FileAnnotations) to the views.

            This could be used to hide the implementation each plugin
            uses and would provide us with a smoother path to convert
            the plugins (or even let (xml) file based annotations
            coexist with database backed plugins).

            Show
            weigo weigo added a comment - Would you care to outline a roadmap? My understanding of the affected plugins is very limited so my view of the problems is rather narrow. I think extracting an interface for supplying the relevant data could be the first step. This would encapsulate how a plugin provides its data (in form of FileAnnotations) to the views. This could be used to hide the implementation each plugin uses and would provide us with a smoother path to convert the plugins (or even let (xml) file based annotations coexist with database backed plugins).
            Hide
            trajano Archimedes Trajano added a comment -

            You can try to use the Java BDB project which provides a Map implementation that is backed by a BDB. That would at least eliminate the immediate problem caused by having a large in memory HashMap.

            Show
            trajano Archimedes Trajano added a comment - You can try to use the Java BDB project which provides a Map implementation that is backed by a BDB. That would at least eliminate the immediate problem caused by having a large in memory HashMap.

              People

              • Assignee:
                drulli Ulli Hafner
                Reporter:
                frohman frohman
              • Votes:
                5 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: