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

memory leak in Build Pipeline plugin (BuildForm)

      (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.

          [JENKINS-16961] memory leak in Build Pipeline plugin (BuildForm)

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

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

          Uwe Stuehler added a comment -

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

          Uwe Stuehler added a comment - Describe a new workaround: killing the session that contains the leak.

          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.

          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.

          evernat added a comment - - edited

          this issue is perhaps related to JENKINS-16341

          evernat added a comment - - edited this issue is perhaps related to JENKINS-16341

          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.

          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.

          Marc Günther added a comment -

          Any progress on this?

          Marc Günther added a comment - Any progress on this?

          Have the same problem!

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

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

              Created:
              Updated: