• Type: Bug
• Resolution: Cannot Reproduce
• Priority: Minor
• Component/s: job-dsl-plugin, remoting
• Labels:

  None
• Environment:

  Jenkins 2.67
  job-dsl 1.64

1. ExportTable.dump.txt

   41 kB

   2017-09-04 09:45

2. 

   paths_to_loader.png

   65 kB

   2017-08-29 06:49

[JENKINS-46514] ClassLoader leak in remoting with job-dsl plugin

Petres Andras created issue - 2017-08-29 06:58

Daniel Spilker made changes - 2017-08-29 07:17

Assignee

Original: Daniel Spilker [ daspilker ]

New: Oleg Nenashev [ oleg_nenashev ]

Petres Andras made changes - 2017-08-29 07:26

Description

Original: We have the same issue as JENKINS-30832 and we suspected a classloader leak, that is why we did some heap dumps. What we found is that after running the seed job (which processes N groovy scripts) M times, there were N*M GroovyClassLoaders retained. YourKit Java Profiler showed us that each of them loaded the classes (mostly closures) from one of our N groovy scripts. We also traced what is retaining the classloaders and we ended up at the _unexportLog_ field of _hudson.remoting.ExportTable_. We didn't fully understand why was it retaining the classloaders, see the screenshot attached (the majority of _LinkedList_ nodes was cut out). _ul_rsp_ is one of the groovy scripts processed, the adress _172.17.0.1_ corresponds to the node the seed job was running on. As a workaround hudson.remoting._ExportTable.unexportLogSize_ was set to 0 to prevent adding entries to _unexportLog_. Checking the heap dump revealed that the same amount of GroovyClassLoaders are present but held via weak/soft references only, making them eligible for garbage collection. I should also mention that the classloaders were leaked even after we got rid of the mixins in out seed job.

New: We have the same issue as JENKINS-30832 and we suspected a classloader leak, that is why we did some heap dumps. What we found is that after running the seed job (which processes N groovy scripts) M times, there were N*M GroovyClassLoaders retained. YourKit Java Profiler showed us that each of them loaded the classes (mostly closures) from one of our N groovy scripts. We also traced what is retaining the classloaders and we ended up at the _unexportLog_ field of _hudson.remoting.ExportTable_. We didn't fully understand why was it retaining the classloaders, see the screenshot attached (the majority of _LinkedList_ nodes was cut out). _ul_rsp_ is one of the groovy scripts processed, the adress _172.17.0.1_ corresponds to the node the seed job was running on. As a workaround hudson.remoting._ExportTable.unexportLogSize_ was set to 0 to prevent adding entries to _unexportLog_. Checking the heap dump revealed that the same amount of GroovyClassLoaders are present but held via weak/soft references only, making them eligible for garbage collection. I should also mention that the classloaders were leaked even after we got rid of the mixins in the seed job.

Petres Andras made changes - 2017-09-04 09:45

Attachment

New: ExportTable.dump.txt [ 39574 ]

Daniel Spilker made changes - 2018-02-15 14:23

Assignee	Original: Oleg Nenashev [ oleg_nenashev ]	New: Daniel Spilker [ daspilker ]
Resolution		New: Cannot Reproduce [ 5 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]

Daniel Spilker made changes - 2018-04-14 13:38

Status

Original: Resolved [ 5 ]

New: Closed [ 6 ]