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

memory leak in Build Pipeline plugin (BuildForm)

    Details

    • Similar Issues:

      Description

      (This issue was likely also reported on Google Code by someone else but never answered.)

      We're suffering from a severe memory leak that seems to be coming from the Build Pipeline plugin, growing with each HTTP request for the build pipeline view.

      Analysis

      We took a heap dump after just one work day of run-time and ran jhat on it. The graph shows memory usage growing almost linearly over the course of a day and the heap analysis shows an unusually high number of instances of the class au.com.centrumsystems.hudson.plugin.buildpipeline.BuildForm.

      Instance Counts for All Classes (excluding platform)
      
      806069 instances of class org.kohsuke.stapler.bind.BoundObjectTable$1 
      800273 instances of class au.com.centrumsystems.hudson.plugin.buildpipeline.BuildForm 
      800273 instances of class au.com.centrumsystems.hudson.plugin.buildpipeline.PipelineBuild 
      51265 instances of class hudson.util.CopyOnWriteList 
      31526 instances of class hudson.util.DescribableList 
      30784 instances of class [Lorg.apache.commons.jexl.parser.Node; 
      24643 instances of class jenkins.model.lazy.BuildReference 
      24228 instances of class net.bull.javamelody.CounterRequest 
      22565 instances of class com.thoughtworks.xstream.core.util.ConcurrentWeakHashMap$HashEntry 
      22565 instances of class com.thoughtworks.xstream.core.util.ConcurrentWeakHashMap$WeakKeyReference 
      18441 instances of class hudson.model.View$PropertyList 
      

      Workaround

      • In issue 143 on Google Code, the reporter also mentioned that they downgraded the plugin to version "1.2.3".
      • We were restarting Jenkins every night, which caused other problems.
      • For now, we're able to free up memory by identifying the session that keeps refreshing the pipeline view and killing that session.

        Attachments

          Issue Links

            Activity

            Hide
            ustuehler Uwe Stuehler added a comment -

            What's being leaked are BuildForm and BuildPipelineForm instances from the buildGrid matrix. They are referenced in a HashMap within Winstone's sessionData, created by Stapler with this code in src/main/resources/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildPipelineView/bpp.jelly:

            //add build proxy to proxies for future use
            buildPipeline.buildProxies[${build.getId()}] = <st:bind value="${build}" />;
            
            Show
            ustuehler Uwe Stuehler added a comment - What's being leaked are BuildForm and BuildPipelineForm instances from the buildGrid matrix. They are referenced in a HashMap within Winstone's sessionData , created by Stapler with this code in src/main/resources/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildPipelineView/bpp.jelly : //add build proxy to proxies for future use buildPipeline.buildProxies[${build.getId()}] = <st:bind value="${build}" />;
            Hide
            ustuehler Uwe Stuehler added a comment -

            Describe a new workaround: killing the session that contains the leak.

            Show
            ustuehler Uwe Stuehler added a comment - Describe a new workaround: killing the session that contains the leak.
            Hide
            evernat evernat added a comment - - edited

            For information, and since you are already using the monitoring plugin, you may be able to view the number of instances per class, without taking a heap dump, but with the "Heap histogram" link in the monitoring reports. See an example in the javamelody demo (click on "Details" on the right to see more classes):
            http://demo.javamelody.cloudbees.net/monitoring?part=heaphisto
            or http://demo.javamelody.cloudbees.net/monitoring?part=heaphisto&format=json

            You can also kill a session with a simple button in the monitoring plugin. Example in the demo (sessions may be empty in the demo at the moment):
            http://demo.javamelody.cloudbees.net/monitoring?part=sessions
            Note that I am not sure if the mega-size of the leaking session may cause a problem to display this sessions page in your server.

            Show
            evernat evernat added a comment - - edited For information, and since you are already using the monitoring plugin, you may be able to view the number of instances per class, without taking a heap dump, but with the "Heap histogram" link in the monitoring reports. See an example in the javamelody demo (click on "Details" on the right to see more classes): http://demo.javamelody.cloudbees.net/monitoring?part=heaphisto or http://demo.javamelody.cloudbees.net/monitoring?part=heaphisto&format=json You can also kill a session with a simple button in the monitoring plugin. Example in the demo (sessions may be empty in the demo at the moment): http://demo.javamelody.cloudbees.net/monitoring?part=sessions Note that I am not sure if the mega-size of the leaking session may cause a problem to display this sessions page in your server.
            Hide
            evernat evernat added a comment - - edited

            this issue is perhaps related to JENKINS-16341

            Show
            evernat evernat added a comment - - edited this issue is perhaps related to JENKINS-16341
            Hide
            ustuehler Uwe Stuehler added a comment -

            Thanks for your comments!

            Superficial thought: Assuming that WithWellKnownURL avoids the generation of a random UUID in the URL for the JS proxy, it might help in this situation.

            I was already thinking... Why are BuildForm and BuildPipelineForm accessed via random URLs when they refer to exactly one "build" or "build pipeline". They should have a well-known URL to access them.

            Show
            ustuehler Uwe Stuehler added a comment - Thanks for your comments! Superficial thought: Assuming that WithWellKnownURL avoids the generation of a random UUID in the URL for the JS proxy, it might help in this situation. I was already thinking... Why are BuildForm and BuildPipelineForm accessed via random URLs when they refer to exactly one "build" or "build pipeline". They should have a well-known URL to access them.
            Hide
            marc_guenther Marc Günther added a comment -

            Any progress on this?

            Show
            marc_guenther Marc Günther added a comment - Any progress on this?
            Hide
            patbos Patrik Boström added a comment -

            Have the same problem!

            Show
            patbos Patrik Boström added a comment - Have the same problem!

              People

              • Assignee:
                dalvizu Dan Alvizu
                Reporter:
                ustuehler Uwe Stuehler
              • Votes:
                6 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated: