|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/src/main/java/jenkins/model/lazy/BuildReference.java
core/src/main/java/jenkins/model/lazy/LazyBuildMixIn.java
http://jenkins-ci.org/commit/jenkins/ad65cecc7825693af7378d1d223966bac40ef37a
Log:
[FIXED JENKINS-22395] redoing the fix in f1430a2
Based on the last few commits, I proved that the original fix in f1430a2
doesn't really address the problem.
That is, once b2 is deleted, and after sufficient garbage collection,
we can make b2.previousBuild.get() be null, and then
b2.getPreviousBuild().getNextBuild() ends up incorrectly returning b2.
In this commit, I roll back that part of f1430a2, and then fix the
problem differently.
I started thinking that the main problem we are trying to fix here
is that the deleted build object should be unreferenceable. That is,
it should behave almost as if the object has already been GCed.
The easiest way to do this is to clear a BuildReference object,
since we always use the same BuildReference object for all inbound
references.
This change allows us to clear BuildReference. Code like
b2.getPreviousBuild() will continue to try to update
b1.nextBuildR to b2, but it will only end up wiping out the field,
only to have b1.getNextBuild() recompute the correct value.
This fix makes both test cases pass in LazyBuildMixInTest.
(cherry picked from commit b6226ad2d1a332cb661ceb5c5f5b673771118e14)