Community
Participate
Working Groups
N20080111-0010. Got the following trace failure in this nightly build: Index file should be unchanged!!! expected:<1200046881796> but was:<1200046887156> junit.framework.AssertionFailedError: Index file should be unchanged!!! expected:<1200046881796> but was:<1200046887156> at org.eclipse.jdt.core.tests.model.JavaSearchBugsTests.testBug181488a(JavaSearchBugsTests.java:8529) While re-running the test I sometimes reproduce it but not systematically...
Created attachment 86926 [details] Proposed patch This patch only fixes the test itself. It seems that some previous tests make some changes to the JavaSearchBugs project which implied a re-indexing. But as there was not enough changes in the indexes, they were not saved on disk. So, when simulating exit, the save occurred but I stored the index file before it really happened => simply move the storage of the index file last modification date between the exit and the restart solve the problem :-)
Released for 3.4M5 in HEAD stream.
The code in HEAD, released on the 15th of January, is markedly different from the patch attached here, and there is no warranty that the result won't fail at some random time (since the assert is back). I hence seems to me that sole the fact that releng tests pass repeatedly could lead to a VERIFIED status here. There have been quite a few nightly builds without this bug being hit again, but in the tens range only. Given the fact that a quick fix is possible (revert to assume), I'll mark this one as verified though. Verified for 3.4 M5 (looking at the code and considering latest releng tests).
Created attachment 88868 [details] Released patch Indeed, I attached the wrong patch file :-( This one was the real released code...
(In reply to comment #3) > The code in HEAD, released on the 15th of January, is markedly different from > the patch attached here, and there is no warranty that the result won't fail > at some random time (since the assert is back). I hence seems to me that sole > the fact that releng tests pass repeatedly could lead to a VERIFIED status here. > There have been quite a few nightly builds without this bug being hit again, > but in the tens range only. Given the fact that a quick fix is possible (revert > to assume), I'll mark this one as verified though. > > Verified for 3.4 M5 (looking at the code and considering latest releng tests). > No, it will never happen again as the index file last modified time is now stored after the exit where an ultimate save may occur if the index manager didn't do it between the last time the indexes were verified to be ready and when the simulated exit happens. So, there's still no reason that this last modified time changes for the index file (except a regression in this area), hence justify that the assertion was put back... Note that run locally RunJavaSearchTests suite 5 times without the fix results to get the test failure on 3 runs (60%). The test was *always* successful on 5 runs with the fix, so I would have been really surprised if this bug hadn't granted to VERIFIED status...
