|
||||||||
|
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:
test/src/test/java/jenkins/model/lazy/LazyBuildMixInTest.java
http://jenkins-ci.org/commit/jenkins/4910863dbdb944f249fa86c4ca583e53c736ed69
Log:
JENKINS-22395I'm not sure if I understand how the original fix in PR #1190 (f1430a2) addresses the problem.
My understanding is of the problem is as follows:
that process sets up a bi-di link via b1<
>b2 via b1.nextBuildR <> b2.previousBuildRPresumably f1430a2 addresses this somehow, but I think I can induce this situation in other ways,
which is what dropLinksAfterGC2() does.
In this test,
initial state:
b1 <
> b2 <> b3we load everyone and connect them all up
after deleting b2:
b1 <--------> b3
^ ^
---- b2 ----
b1 and b3 points each other, and b2 still refers to each side
after dropping b1:
b2 --> b3
now, here, when I do b2.getPreviousBuild(), it loads b1a and it sets b1a.nextBuildR to b2.
b1a <-> b2 --> b3
So I claim this is a proof that the fix is incomplete, even for the problem
JENKINS-22395has discovered.I don't think that the problem is for the dropLinks call to fail to patch up references.
The problem is that b2.getPreviousBuild() forcing b1 to point to b2, because if b2 is deleted and assumed to be
invalid, then no matter what bX this method will find you never want bX.nextBuildR to point to b2.
(cherry picked from commit 53e95ee517259e1e10d7209bcbaa4314397c1f40)