-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak introduced with the fix of JENKINS-36372 #41
Memory leak introduced with the fix of JENKINS-36372 #41
Conversation
…cting a memory leak regression introduced with the fix of JENKINS-36372 in 2.9.
@@ -63,6 +63,7 @@ | |||
</pluginRepositories> | |||
<properties> | |||
<jenkins.version>1.642.3</jenkins.version> | |||
<jenkins-test-harness.version>2.15-SNAPSHOT</jenkins-test-harness.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Downstream of jenkinsci/jenkins-test-harness#32. Actually passes without this dependency, but takes three times as long to collect the reference, due to lack of exponential escalation in the original version.
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
@Test public void loaderReleased() { | ||
story.addStep(new Statement() { | ||
@Override public void evaluate() throws Throwable { | ||
Assume.assumeThat("TODO fails in Jenkins 2 for reasons TBD (no root references detected)", Jenkins.VERSION, Matchers.startsWith("1.")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional calls to fromRoots
in the upstream PR were an attempt to diagnose this, so far without success.
Seem to be test failures, trying to figure out what they mean. |
…tly be null in cleanUpHeap.
@@ -391,6 +393,10 @@ private void run() throws IOException { | |||
if (doneSomeWork) { | |||
saveProgram(); | |||
} | |||
if (ending) { | |||
execution.cleanUpHeap(); | |||
scripts.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clearing scripts
(introduced in #29) was also necessary, or even with the fix to the timing of SerializableClassRegistry.release
, the test would still fail on Jenkins 1. The failure showed no root references, so I had to guess at the cause.
FindBugs failure, will deal with it. In the meantime I found the cause of the Jenkins 2 failure at last:
Unless you are running on IBM J9 VM, Groovy 2 switches to a broken |
With a patched INSANE, I can now diagnose the problem properly in the test:
|
…mething else leaking in Jenkins 2.
Fixed that problem what I can tell, but now the test fails again on Jenkins 2 with no apparent GC root path. Heap analysis tools just tell me that the |
|
||
// clean up heap | ||
void cleanUpHeap() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SerializableClassRegistry.release
was getting called on the right loader, but too soon—before the final call to saveProgram
, which would up adding the loader back to the registry. Not sure when this regressed—presumably at some point after the test was disabled.
🐝 |
Added support for super.foo(...) calls
Had disabled a test due to still-undiagnosed failures on Jenkins 2, which concealed the fact that a recent bug fix (#29) regressed the leak on Jenkins 1:
@reviewbybees