Community
Participate
Working Groups
Using I20080108-1320 build. Suddenly the Open type dialog stops to work for the classes of one of my project in my workspace (unfortunately org.eclipse.jdt.core project)... Nothing obvious in the Search Engine was displayed: the scope used is the JavaWorkspaceScope and the pattern looks OK.
Hopefully, I was able to debug this problem in my self-hosted eclipse session and discovered that the project was no longer in the JavaWorkspaceScope. I'll investigate further, but set as major as this make the session hard to use!
Unfortunately, I didn't clearly understand what was the reason of this problem when it occurred in my workspace. I wrongly thought I had the explanation and restart my eclipse session to verify my assumption but I wasn't able to reproduce the problem since then :-( So, I reduce the severity and priority for now and I'll try to catch this issue more properly the next time (approx. once per month!)...
I see this (or something similar to it in I20080708-0830 Open type will not find some classes in org.eclipse.jface. If I type Action it offers the jface Action as an option. If I type MenuManager, it offers a random choice as the first selection and then MenuManagerTest as the second one. But MenuManager is there (I checked :-) PW
Created attachment 107106 [details] Example with a non-named type as the first selection I can open a separate bug if you'd like (since this doesn't effect all classes in org.eclipse.jface, just specific ones) PW
Sorry, I don't believe my problem is related to this, please disregard comment #3 and comment #4 Opened bug 240363 to track my issue. PW
I got it once again and for the same project: org.eclipse.jdt.core... However, this time the workspace scope was valid (i.e. it includes the project). The problem was that index file was not found in the .metadata although the Index was still referenced by IndexManager.indexes table...
I now got this issue in a recurrent manner :-( Tracking down in a remote debug session I saw that in fact the Index for the org.eclipse.jdt.core project was no longer referenced in the indexes lookup table but there's still an entry for its path in the indexLocations lookup table! Furthermore, this entry refers to the index of another Index file: org.eclipse.jdt.core.tests.model, hence there's no chance to find any match in the org.eclipse.jdt.core project!!! Kent, do you see any reason why the indexLocations table may have been messed up and could return the location of an other index file? Looking at the code, it appears that the only place where the indexLocations table is modified is in IndexManager.computeIndexLocation(IPath) which is not synchronized, could it be a possible explanation? Any hints on this would be greatly appreciated :-)
There are 11 direct senders of computeIndexLocation() & 7 are already synchronized & IndexManager.saveIndex(Index) uses a sync block inside The other 3 are : IndexManager.addBinary(IFile, IPath) IndexManager.addSource(IFile, IPath, SourceElementParser) IndexSelector.initializeIndexLocations() It seems like a reasonable change to synchronize computeIndexLocation(). Some methods are using the ReadWriteMonitor on the index, but I suggest you double check the code into the 3 methods above.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Kent Johnson from comment #8) > There are 11 direct senders of computeIndexLocation() & 7 are already > synchronized & IndexManager.saveIndex(Index) uses a sync block inside > > The other 3 are : > > IndexManager.addBinary(IFile, IPath) > IndexManager.addSource(IFile, IPath, SourceElementParser) > IndexSelector.initializeIndexLocations() > > It seems like a reasonable change to synchronize computeIndexLocation(). > > Some methods are using the ReadWriteMonitor on the index, but I suggest you > double check the code into the 3 methods above. computeIndexLocation() is synchronized since the fix for bug 320809, and so is the overload added via bug 395897. *** This bug has been marked as a duplicate of bug 320809 ***
