- 11 7月, 2014 5 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
Based on the last few commits, I proved that the original fix in f1430a25 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 f1430a25, 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.
-
由 Kohsuke Kawaguchi 提交于
As I step-executed the code, I discovered b2.getPreviousBuild() was getting invoked between BRHF.drop(b1) and b2.dropLinks() call, in PeepholePermalink.RunListenerImpl.onDeleted() because Run.delete() calls RunListener.fireDeleted(this). Thus in effect the sequence of the call order was as follows: assertEquals(1, BRHF.drop(b1)); b2.getPreviousBuild(); // happens indirectly in PeepholePermalink b2.delete(); FreeStyleBuild b1a = b2.getPreviousBuild(); This defeats the purpose of the fix, because in this call sequence, by b2.dropLinks() as implemented before f1430a25 will correctly fix up b1a.nextBuildR to b3. For the test to work as intended, it is important that b2.previousBuildR.get()==null during dropLinks(). That is what causes b2.getPreviousBuild() in the next line to go load b1a, and sets up b1a.nextBuildR to b2, and trigger the assertion error. Added a code to remove all RunListeners. With this change, the test now fails without the fix in f1430a25.
-
由 Kohsuke Kawaguchi 提交于
I'm not sure if I understand how the original fix in PR #1190 (f1430a25) addresses the problem. My understanding is of the problem is as follows: - someone deletes 'b2' but holds on to its reference (could be different threads) - someone calls b2.getPreviousBuild() - if b2.previousBuildR is null, then this triggers the loading of b1, and that process sets up a bi-di link via b1<->b2 via b1.nextBuildR <-> b2.previousBuildR - this makes b1.getNextBuild() incorrectly return b2 Presumably f1430a25 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 <-> b3 we 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-22395 has 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.
-
由 Kohsuke Kawaguchi 提交于
-
- 09 7月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
WARNING: Caught exception evaluating: e.hasStopPermission() in /. Reason: java.lang.NullPointerException java.lang.NullPointerException at hudson.model.Executor.hasStopPermission(Executor.java:523)
-
- 08 7月, 2014 4 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 07 7月, 2014 8 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Oleg Nenashev 提交于
[FIXED JENKINS-23683] Check whether war's directory is writable
-
由 Stephen Connolly 提交于
Return correct URL to Jenkins master node
-
由 Stephen Connolly 提交于
[FIXED JENKINS-23294] Interpret X-Forwarded-Port
-
由 tfennelly 提交于
-
- 04 7月, 2014 1 次提交
-
-
由 Daniel Beck 提交于
-
- 02 7月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
Fix documentation.
-
- 01 7月, 2014 2 次提交
-
-
由 Kanstantsin Shautsou 提交于
-
由 Jesse Glick 提交于
Reverts 66528e43 so as to make test cases more faithful to real behavior.
-
- 30 6月, 2014 9 次提交
-
-
由 Daniel Beck 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Harald Albers 提交于
[FIXED JENKINS-21716] Set Content-Type header for env-vars.html
-
- 29 6月, 2014 2 次提交
-
-
由 Oleg Nenashev 提交于
Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>
-
由 Oleg Nenashev 提交于
[FIXED JENKINS-20086] Allow disabling use of default exclude patterns (.git, .svn, etc.)
-
- 28 6月, 2014 2 次提交
-
-
由 Daniel Beck 提交于
-
由 Kohsuke Kawaguchi 提交于
Reference: https://trello.com/c/doFFMdUm/46-filepath-getcomputer
-
- 27 6月, 2014 4 次提交
-
-
由 Oleg Nenashev 提交于
Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>
-
由 Harald Albers 提交于
[JENKINS-23595] - Fix makeFlash script bug with ImageMagick v6.7.9+
-
由 Oleg Nenashev 提交于
Fix a NPE when the 'properties' element is missing from the form's JSON
-
由 Kyle Beal 提交于
switched off alpha before colorizing temporary gifs when making animated balls. prevents colorize from applying fill to alpha channel. alpha is turned back on after colorize operation
-
- 26 6月, 2014 1 次提交
-
-
由 Oliver Gondža 提交于
-