Community
Participate
Working Groups
Build 20011108 When the hard-disk is full, the indexer can choke while trying to save. This is a borderline case, but since indexes write alot to disk, it's not unheard of. Here's the stack trace: java.lang.ArrayIndexOutOfBoundsException: 883 at org.eclipse.jdt.internal.core.index.impl.MergeFactory.mergeFiles(MergeFactory.ja va:136) at org.eclipse.jdt.internal.core.index.impl.MergeFactory.merge(MergeFactory.java:77 ) at org.eclipse.jdt.internal.core.index.impl.Index.merge(Index.java:231) at org.eclipse.jdt.internal.core.index.impl.Index.save(Index.java:340) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndexes(IndexMana ger.java:335) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.notifyIdle(IndexManag er.java:267) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:2 54) at java.lang.Thread.run(Thread.java:498)
This failure mode is bad, because if I shutdown the workbench, clear up enough space on my hard-disk, and then restart, I get another error: java.lang.ArrayIndexOutOfBoundsException: 1551 at org.eclipse.jdt.internal.core.index.impl.MergeFactory.mergeFiles(MergeFactory.ja va:136) at org.eclipse.jdt.internal.core.index.impl.MergeFactory.merge(MergeFactory.java:77 ) at org.eclipse.jdt.internal.core.index.impl.Index.merge(Index.java:231) at org.eclipse.jdt.internal.core.index.impl.Index.save(Index.java:340) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndexes(IndexMana ger.java:335) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.notifyIdle(IndexManag er.java:267) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:2 54) at java.lang.Thread.run(Thread.java:498)
Would this be related to the other merge issue we have been seeing ? Protection should probably be added, no problem if the index is left inconsistent beyond that point, since there is no more disk space anyway.
By any chance, do you still have the workspace that when restarted caused the second stack trace?
No I don't have the old workspace. Sorry, I should have kept it. Here is a fairly easy way to reproduce the initial error: 1) Start with lots of disk space free 2) Create a java project with lots of classes 3) Delete the project, but don't delete content from disk 4) Fill the disk to within about 20K of being full 5) Recreate the java project on the existing content Step 5 should kick in a large index operation that will fill the disk and cause the indexer errors. I also found it best to work with the test workspace on a floppy drive, as this makes it easier to fill the disk without crashing other things (such as your dev environment).
Problem was that on the second merge (i.e. when part of the index was on disk), we got an IOException because of the full disk. However the file numbers in the InMemoryIndex had already been updated. So next time we tried to merge (i.e. when the index manager was idle), we failed with an ArrayIndexOutOfBoundsException as the 'merge' algorithm expected the file numbers of the InMemoryIndex to start with 1.
*** Bug 5837 has been marked as a duplicate of this bug. ***
