Community
Participate
Working Groups
With fix for bug 12044, attached sources of a jar file are indexed using a low priority. This low priority means that as soon as a search request is done, it will be executed immediately even if the indexing is not finished as soon as it does not need such indexes. The problem is that the PatterSearchJob ran for the request stores all the indexes in a local array (see the method execute(IProgressMonitor)) and, at the same time, the indexing of the attached sources can modify the index files (i.e. call IndexManager.saveIndex(Index)). So, in this case, there would be a high probability that indexes in the array do not longer match the indexes of the IndexManager, hence got unpredictable results while reading them (usually an OOME)... This is shown by the patch for bug 12044: https://bugs.eclipse.org/bugs/attachment.cgi?id=115273 but it's a potential issue for all callers of IndexManager.getIndexes(IPath[], IProgressMonitor) which may stores the array locally, hence needs a general fixes to prevent such kind of troubles...
Created attachment 118573 [details] Proposed patch Patch extracted from last bug 12044 patch and improved a little bit. With this patch, the index is not recreated while indexing a jar file, but reset instead. This avoid a running request to lose the index pointer if a re-indexing occurs concurrently (see PatternSearchJob.execute(IProgressMonitor) method)... Note that the index will be recreated if none is found while resetting it...
Created attachment 118574 [details] Real proposed patch Previous patch included temporary changes DiskIndex which I think are not finalized yet...
Created attachment 118575 [details] Final? proposed patch I got some troubles this morning with patches... Previous one has a compiler error!
Jerome, Kent, could you have a look on the patch and let me know your mind about it? TIA
(In reply to comment #3) It looks like the index file is reused when reset (actually only the header is reused). I'm not sure what the content of the header is, but it might be safer to do as before: delete the file and recreate it from scratch.
(In reply to comment #5) > (In reply to comment #3) > It looks like the index file is reused when reset (actually only the header is > reused). I'm not sure what the content of the header is, but it might be safer > to do as before: delete the file and recreate it from scratch. > Good point. I thought it could be a possible optimization not delete/recreate the index file, but then we would keep categories tables offset in the header which make its contents invalid. It seems that the DiskIndex.initialize(boolean) can be used only for to clone DiskIndex objects when the argument is true...
Created attachment 118601 [details] Last proposed patch
Released for 3.5M4 in HEAD stream. Unfortunately it was not possible to write test for the fix of this bug. I'm afraid that only code review can be done to verify it...
Created attachment 118611 [details] Last patch improvement Additional change to always create a new index file while resetting the Index. Thanks Jerome :-)
Verified for 3.5M4 using I20081209-0100
*** Bug 241592 has been marked as a duplicate of this bug. ***
