Community
Participate
Working Groups
I have a case where a variable in my workspace shows zero for "references in workspace". Whis is obviously incorrect. For example, "references in file" finds 40+ entries. I tried cleaning the workspace. No effect. The project builds and runs without error. There is no crash data, or other apparent indication that the reported count of zero may be incorrect. I would like to know how to clear this condition, if it is caused by a corrupt cache or something of the sort, but the alarming circumstance is that the count is wrong at all.
Created attachment 26819 [details] supporting screen shot the counts can also be incorrect in less obvious ways. Here, I have a case where the count of references is reported as 4. If I add an X to the variable declaration, which forced all the references to generate errors, there are 9 or them. If I retype the varaible name the errors go away, and the reference count returns to 4. All without any indication that eclispse is having any problem.
Created attachment 26820 [details] part 2, the other state of the variable/reference count.
Works for me. Please provide the code or a test case that shows the behavior. See also: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/development/bug-incomplete.htm
well, it "usually" works for me too, just this particular case seems to be incorrect. I have the entire workspace saved, which probably would let you reproduce the problem, but it's 60 mb (due to history bloat, see one of my other bug reports). I suspect it must be due to a damaged cache somewhere. Perhaps if you told me where to look, I could figure out what's damaged. The problem is presumably not that this particular cache is corrupted (all caches will eventually be corrupted - shit happens), but that the corrupt cache is not being detected as corrupt or cleared by operations such as "clean" on the project. BTW, this is not simply cosmetic - other operations such as refactor/rename seem to depend on it too, and if I'm surveying the use of a variable, I need to be able to TRUST operations such as "show references", or I'd be better off going back to using text searches.
>I suspect it must be due to a damaged cache somewhere Exit the workbench and delete the Java search index: - go into <workspaceDir>\plugins\.metadata\.plugins\org.eclipse.jdt.core - delete 'savedIndexNames.txt' - delete all *.index Restart
Dave, an isolated test case would be really helpful here. Without it it will be very hard to track this down. Moving to JDT/Core since this is Java search.
Unfortunately your screenshots do not help us a lot. Try to reproduce in your workspace using a *very* small test case. Ideal would be to have this test case in a brand new project but if you cannot reproduce it, then at least we need: 1) build ID 2) class where you're expecting to find match(es) and search fails them 3) how do you launch the search (search dialog/menu item) 4) the precise kind of search you performed (type/field/method, scope, case sensitive, etc.) Thanks
deleting the "savednames" and *.index does fix the problem. I've managed to prune my damaged workspace down to "only" 10 mb. I can provide that if you'll designate where to upload it. I hope you're thinking about defense in depth here. Whatever the nature of the corruption, it should be detected automatically, or lacking that, cleaned up as part of some automatic process "just in case". And of course, the cache shouldn't become corrupt in the first place, but reality is that all caches will eventually be corrupted.
additional good news, my small 10mb test case also fails when transferred to a new machine I am setting up. This new machine is at present completely virgin, so I'm fairly confident you will be able to see the problem in your environment.
We do not have any public FTP server site. The only way for me to get your workspace would be that you put it somewhere I can download it...
Maybe I am wrong regarding the scope of "references in workspace" but I have another problem with this search functionality: I have a project "A" which creates some objects by reflection (and references the appropriate projects providing the needed classes). Since I know the class name I inserted it into project "B" and tried "references in workspace" which gives me the error: The operationis unavailable to the current collection. Please select a valid element name. I didn't expected the class to work since I didn't reference the project providing it, but I expected the search functionality to lead me to the required project in the workspace. However if I use the "Java search" and search for the same class name it returns the correct class/project.
(In reply to comment #11) Victor, Do NOT use a bug to ask question about eclipse even if subject are similar (which is not the case here...). You're polluting the bug tracking and slows its fixing... To ask question, please use newgroup instead: news://news.eclipse.org/eclipse.tools.jdt
please provide an email address where I can send you the link to the test case privately. (I don't want to post my source code publicly.)
(In reply to comment #12) Sorry for the spam. Since I am not familiar with the code I thought it might be related because the seemingly same search gives two different results in my case.
frederic_fusier@fr.ibm.com FYI, you can see email address of bug assignee in bug "Assigned To" field.
I successfully got your workspace and I can now reproduce your issue. Thanks
Didn't you have any .log file in your original workspace (ie. in G:\share\projects\eclipse directory)? If so, would it be possible to attach it to this bug or send it to me? Problem comes from incorrect index and I hope we can find in log file the reason of this failure (indexing should have log if it failed while indexing a project). Thx
I also still need build ID on which this problem occurs...
(In reply to comment #18) > I also still need build ID on which this problem occurs... > Version: 3.1.0 Build id: I20050627-1435
I'm seeing this behavior, too. Looks like the all reference searches fail, even for methods referred to within the java file (but "Occurrences in File" search works). Deleting the metadata files (comment #5) doesn't help. Version 3.1.2.
(In reply to comment #20) > I'm seeing this behavior, too. Looks like the all reference searches fail, > even for methods referred to within the java file (but "Occurrences in File" > search works). Deleting the metadata files (comment #5) doesn't help. Version > 3.1.2. > If deleting the metadata files doesn't help, then I assume this is not the same problem. Please describe it more precisely, also try to reproduce in a brand new wkps and/or in a new project and then we can see if it's the same or if you need to open a new bug report, thanks
I observed the same "references in workspace" invalid results here, but that was not the only issue. My class hierarchy was also corrupted as well (some subclasses were missing). Cleaning the workspace or modifying the referencing/referenced code did not help, but deleting the cache files fixed everything. It looks like to me that for some reason the index becomes incomplete and stays that way (forcing a new compilation of the implicated code surprisingly does not refresh the missing parts).
(In reply to comment #22) ... > It looks like to me that for some reason the index becomes incomplete and stays > that way (forcing a new compilation of the implicated code surprisingly does > not refresh the missing parts). > You're right and attach your .log file to this bug will perhaps help us to understand what happened to put indexing in this unexpected state...
If you look back to comment #16, you will see that I provided a test case showing the corrupted state approximately 6 months ago. I'm repeating myself, but "shit happens". Any caching scheme man can devise will eventually be corrupted by some accident. Aside from the desirablily of avoiding this as much as possible, SOME routine operation ought to detect and clean up the problem. CLEAN is an excellent candidate IMO.
(In reply to comment #24) > If you look back to comment #16, you will see that I provided a > test case showing the corrupted state approximately 6 months ago. > And if you look back to my answer in comment 17, you'll see that even if I was able to reproduce your problem I was not able to find any .log file to have a chance to figure out what happened in the indexes... > I'm repeating myself, but "shit happens". Any caching scheme man > can devise will eventually be corrupted by some accident. Aside > from the desirablily of avoiding this as much as possible, SOME > routine operation ought to detect and clean up the problem. > CLEAN is an excellent candidate IMO. > I agree but it would be better to know what was the origin of the problem. That's while I'm asking for a .log file when this problem is noticed. It's not sure but it may provide us more information to understand what was the crash during the indexing operation and have a chance to avoid it in the future...
I have made a few other observations and found a possible workaround which make me think that the issue is more tricky. I was facing the issue recurently since my last comment. I have deleted the index files several times and although the index looked fine after restarting Eclipse, it very quickly became corrupted/incomplete again after some use of Eclipse. I have then noticed that deleting the index files was even not needed, simply restarting Eclipse restored the index as well. It looks like the index gets corrupted in memory rather that on the disk (or at least in a greater way). As I have only observed the issue with big projects, it felt like a memory shortage to me... I tried to increase Eclipse memory, and my index has looked complete ever since. Anyway, my .log file remains desperately empty. Wether the JVM runs out of memory or the cause is different, nothing is logged.
That's a good point. I looked at code and indeed, IndexManager will fail silently on OOME... :-( Dave, may you give a try with an higher Xmx value and let me know if this fix the problem? If so, then I think I'll add a trace for this kind of failure during indexing...
Ooops, JobManager already do trace OOME, so either due to OOME, it cannot write in .log file or as Julien said, the cause is different. By the way, I'm still interested to know whether increase the Java Heap size fixes the problem for you Dave. This may give a clue to know whether it's a possible memory issue or not...
I'm not actively experiencing this problem, but I did increase memory at some point because of heavy graphics demands. However nice it might be to log "out of memory", it hardly seems appropriate to ignore it and push on without memory. Other bad things seem likely to occur.
We do not keep silent on exception, comment 27 was wrong... As I (quickly) said in comment 28, we currently log OutOfMemoryException (in fact JobManager, which is the super class of IndexManager, logs all exception when possible). We do want to know when shit happens and this is what I try to do... However, we also need test cases to reproduce problems to have a chance to understand and fix them. Currently, without any other information, it's hard to track the origin of your problem. It seems that increasing the Java Heap size makes it disappearing, so I would think about a non-logged OOME, but it's just a feeling not something I'm 100% sure... We're currently working to increase performances and I'm specifically looking at memory consumption during search/indexing. I'll let you know if I have some feedback about my investigations on this...
I was wrong. Increasing the heap size finally did not solve the problem (for information, I stepped from 256Mo to 512Mo). For some reason or unless it was only a coincidence, the "disease" was slowed down, but the index eventually became corrupted in memory again. I'm currently trying another approach to check wether some workspace disorder triggers the whole thing or not. I have created a fresh workspace and imported preferences and projects from the old one. I gave it a little more time than my last attempt, and so far so good. I will keep you informed about my progress. I also noticed that I was running running Eclipse 3.1.1 back from Eclipse 3.1.2. I installed and tried 3.1.2 but forgot to update some key shortcut... The documentation clearly states that workspaces may become incompatible with previous Eclipse releases. The issue is older than 3.1.2, but that may be another lead.
I had the same kind of problems, that is, doing a reference search on a method would miss occurences I could find by renaming the method and looking in the problems pane, or the type hierarchy would lack some classes. I found this entry in the log: !ENTRY org.eclipse.jdt.core 4 4 2006-05-11 13:49:29.125 !MESSAGE Background Indexer Crash Recovery !STACK 0 java.lang.NoClassDefFoundError: org/eclipse/jst/jsp/core/internal/Logger at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.getELTranslator(JSPTranslator.java:1315) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateEL(JSPTranslator.java:1268) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateEmbeddedJSPInAttribute(JSPTranslator.java:1391) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.checkAllAttributeValueContainers(JSPTranslator.java:1107) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateXMLNode(JSPTranslator.java:1080) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translateRegionContainer(JSPTranslator.java:843) at org.eclipse.jst.jsp.core.internal.java.JSPTranslator.translate(JSPTranslator.java:734) at org.eclipse.jst.jsp.core.internal.java.JSPTranslationAdapter.getJSPTranslation(JSPTranslationAdapter.java:131) at org.eclipse.jst.jsp.core.internal.java.search.JSPSearchDocument.getJSPTranslation(JSPSearchDocument.java:112) at org.eclipse.jst.jsp.core.internal.java.search.JSPSearchDocument.getCharContents(JSPSearchDocument.java:74) at org.eclipse.jst.jsp.core.internal.java.search.JavaSearchDocumentDelegate.getCharContents(JavaSearchDocumentDelegate.java:41) at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:73) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:72) at org.eclipse.jst.jsp.core.internal.java.search.JSPSearchParticipant.indexDocument(JSPSearchParticipant.java:73) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:290) at org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:601) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:372) at java.lang.Thread.run(Thread.java:595) I'm not sure why it doesn't find this class, I do have a jar with it: eclipse/plugins/org.eclipse.jst.jsp.core_1.0.1.v2006021502002350.jar. I'm using eclipse 3.1.2, Build id: M20060118-1600, and the web eclipse tools 1.0.2 (it might have been 1.0.1 at that time). I think this happened after I did the following: - I deleted a project, say P - created some new ones, each including only a sub-directory of project P Deleting the indexes like mentioned in comment 5 solved the problem (thanks for the steps !). Just in case this might help.
I have a project with the order of 1M java files and I have a way to reliably reproduce this: Sync from version control outside eclipse, refresh project (select project in package explorer and F5 or context menu->Refresh), build, run, everything is fine. Then search for a class Ctrl-Shift-T, start typing a class name. Sometimes I can see a message saying "indexing xx%". If I pick a class before this is done the indexes get corrupted and I cannot find classes or references (not all, just some). Deleting the .index files as suggested in this bug seems to fix the problem.
A couple of the guys at work have run into this problem, but it seems to be more general than people are describing in this bug report. The solution that we've found is to stop eclipse, delete the indexes in org.eclipse.jdt.core and restart. But it's more than just not finding references. We also find that type hierarchies are incomplete (and I'm sure there's something else I can't quite remember at the moment). One guy in particular seems to encounter the problem a lot ... to the extent that he's starting to doubt the functions and not use them. So, if there are any logging settings or suggestions I can try, I'm happy to use the guys here as guinea pigs to see what we can find out. We're using eclipse 3.3.1, but we came across the problem in 3.2 as well. I can't say for sure that the problem is worse in 3.3 - but I'm hearing about it more often. That might be because people are using the affected functions more these days. Thanks.
(In reply to comment #33) > I have a project with the order of 1M java files and I have a way to reliably > reproduce this: Sync from version control outside eclipse, refresh project > (select project in package explorer and F5 or context menu->Refresh), build, > run, everything is fine. Then search for a class Ctrl-Shift-T, start typing a > class name. Sometimes I can see a message saying "indexing xx%". If I pick a > class before this is done the indexes get corrupted and I cannot find classes > or references (not all, just some). Deleting the .index files as suggested in > this bug seems to fix the problem. > Sounds interesting if we can get a scenario to constantly reproduce this issue. What do you mean exactly by "pick a class"?
(In reply to comment #34) > A couple of the guys at work have run into this problem, but it seems to be > more general than people are describing in this bug report. The solution that > we've found is to stop eclipse, delete the indexes in org.eclipse.jdt.core and > restart. But it's more than just not finding references. We also find that > type hierarchies are incomplete (and I'm sure there's something else I can't > quite remember at the moment). One guy in particular seems to encounter the > problem a lot ... to the extent that he's starting to doubt the functions and > not use them. > > So, if there are any logging settings or suggestions I can try, I'm happy to > use the guys here as guinea pigs to see what we can find out. > > We're using eclipse 3.3.1, but we came across the problem in 3.2 as well. I > can't say for sure that the problem is worse in 3.3 - but I'm hearing about it > more often. That might be because people are using the affected functions more > these days. > > Thanks. > One first try I have in mind to verify whether the indexes corruption is only in memory or on disk files: when the problem occurs, just leave Eclipse and restart without deleting the indexes files. If the problem is in memory, then it should be enough to fix it...
(In reply to comment #36) > One first try I have in mind to verify whether the indexes corruption is only > in memory or on disk files: when the problem occurs, just leave Eclipse and > restart without deleting the indexes files. If the problem is in memory, then > it should be enough to fix it... I'm afraid not. The general experience was that it was necessary to delete the indexes and restart. Just restarting didn't solve the problem. I thought about giving the developers a start-up script that just did both in one operation.
(In reply to comment #37) > I'm afraid not. The general experience was that it was necessary to delete the > indexes and restart. Just restarting didn't solve the problem. I thought > about giving the developers a start-up script that just did both in one > operation. > Hmm, if this issue occurs systematically, I hope we can figure out what happen rapidly rather than always deleting the index files... One other question, is the OS always Win2K or did you notice it on other kind of boxes (WinXP, Linux,...)?
I can reproduce it on Linux (see comment 33).
(In reply to comment #39) > I can reproduce it on Linux (see comment 33). > That's right, I missed it... Thanks May you answer my question about what did you exactly mean by "pick a class"?
(In reply to comment #40) > (In reply to comment #39) > > I can reproduce it on Linux (see comment 33). > That's right, I missed it... Thanks > May you answer my question about what did you exactly mean by "pick a class"? Pick a class = start typing, some class is the first in the list (selected) and press enter. Also start typing, use down arrow to select some class in the list and press enter. Thanks for looking into this!
(In reply to comment #34) > ... > So, if there are any logging settings or suggestions I can try, I'm happy to > use the guys here as guinea pigs to see what we can find out. > ... You can set debug options for the indexing: 1) create or modify the .options file in the <install dir>/eclipse directory by adding the following lines: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports background indexer activity: indexing, saving index file, index queries org.eclipse.jdt.core/debug/indexmanager=true 2) add -debug and -consoleLog to the command line while launching eclipse 3) then, IMMEDIATELY after the problem occurs, copy all the contents displayed in the DOS Window Eclipse console, paste it into a file and attach this file to this bug. TIA
(In reply to comment #42) > You can set debug options for the indexing: Thanks - done. I'll keep you posted. Just out of curiosity, is there any way to direct debug output to a file? this stuff doesn't seem to end up in the error log (workspace\.metadata\.log) and I haven't spotted (yet) a way to change that.
In your start script you have to redirect the console output to a file.
Lowering priority since we need the debug trace before we can do anything
I am also seeing this behavior on 3.5. I will try to capture the specifics of when it happens using your instructions because I'd love to see this fixed. Can you elaborate on how to redirect that debug log to a file? I couldn't find anything in the documentation.
>Can you elaborate on how to redirect that debug log to a file? See comment 42.
Same problem. Deleting indexes files didn't help. Interesting is the fact that if I search by references->workspace on the interface method, rather then its implementing class method, all occurrences are found... P.S. College using IDEA found all occurrences from implementation class... So I see something is undone with indexing... I am using: SpringSource Tool Suite Version: 2.5.0.M3 Build Id: 201008251000
This bug is a major issue for me. Eclipse "FORGETS" it's indexing consistently. If I restart eclispe the indexing will work (eg. references on a variable) for around about 10 - 20 mins of continuous use, and then, inexplicably, it starts returning 0 references. I have tried: -> Creating a brand new workspace and importing NOTHING to verify the integrity of my workspace. SAME ISSUE. -> Changing versions of eclipse: I moved from Helios to the lastest build of Indigo. SAME ISSUE. This issue has wasted a ridiculous amount of time for me, constantly restarting eclipse, trying to find solutions to the problem. Please help. I am on a 64bit machine using 64 bit version of eclipse.
(In reply to comment #49) > This bug is a major issue for me. Eclipse "FORGETS" it's indexing > consistently. If I restart eclispe the indexing will work (eg. references on a > variable) for around about 10 - 20 mins of continuous use, and then, > inexplicably, it starts returning 0 references. I have tried: > -> Creating a brand new workspace and importing NOTHING to verify the integrity > of my workspace. SAME ISSUE. > -> Changing versions of eclipse: I moved from Helios to the lastest build of > Indigo. SAME ISSUE. > > This issue has wasted a ridiculous amount of time for me, constantly restarting > eclipse, trying to find solutions to the problem. Please help. > > I am on a 64bit machine using 64 bit version of eclipse. Restart always fixes it? Any errors in .log?
Yes, restart ALWAYS fixes it. I've been running with console debugging on for the last week and the most relevant exception I've seen is the following: (Note that this one I've seen the most but others have appeared as well, although they don't look related. I have NOT seen this exception systematically but there is always an exception around when I lose my indexing). Thanks for any feedback. Brett Thread[main,6,main] REQUEST background job - indexing /DevNew/src/rubiconx/far mconnect/database/app/FcActionGroupApp.java Thread[main,6,main] AWAITING JOBS count: 1 Thread[Java indexing,4,main] -> saving index C:\Users\brettw\EclipseWorkspaces\f armconnectWorkspaceIndigo\.metadata\.plugins\org.eclipse.jdt.core\1589233677.ind ex Thread[Java indexing,4,main] -> got the following exception while saving: java.io.FileNotFoundException: C:\Users\brettw\EclipseWorkspaces\farmconnectWork spaceIndigo\.metadata\.plugins\org.eclipse.jdt.core\1589233677.index (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(Unknown Source) at org.eclipse.jdt.internal.core.index.DiskIndex.readAllDocumentNames(Di skIndex.java:576) at org.eclipse.jdt.internal.core.index.DiskIndex.mergeWith(DiskIndex.jav a:503) at org.eclipse.jdt.internal.core.index.Index.save(Index.java:192) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndex( IndexManager.java:774) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndexe s(IndexManager.java:816) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.notifyIdle (IndexManager.java:546) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:388) at java.lang.Thread.run(Unknown Source) Can't find resource for bundle java.util.PropertyResourceBundle, key ERROR_DUPLI CATE_WEB_INF_LIB ERROR_DUPLICATE_WEB_INF_LIB Can't find resource for bundle java.util.PropertyResourceBundle, key ERROR_DUPLI CATE_WEB_INF_LIB ERROR_DUPLICATE_WEB_INF_LIB Thread[Java indexing,4,main] 1 awaiting jobs Thread[Java indexing,4,main] STARTING background job - indexing /DevNew/src/rubi conx/farmconnect/database/app/FcActionGroupApp.java Thread[Java indexing,4,main] FINISHED background job - indexing /DevNew/src/rubi conx/farmconnect/database/app/FcActionGroupApp.java
Another similar exception that occurs: armconnectWorkspaceIndigo\.metadata\.plugins\org.eclipse.jdt.core\1589233677.ind ex Thread[Java indexing,4,main] -> got the following exception while saving: java.io.IOException: Failed to rename index file C:\Users\brettw\EclipseWorkspac es\farmconnectWorkspaceIndigo\.metadata\.plugins\org.eclipse.jdt.core\1589233677 .index at org.eclipse.jdt.internal.core.index.DiskIndex.mergeWith(DiskIndex.jav a:560) at org.eclipse.jdt.internal.core.index.Index.save(Index.java:192) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndex( IndexManager.java:774) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndexe s(IndexManager.java:816) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.notifyIdle (IndexManager.java:546) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:388) at java.lang.Thread.run(Unknown Source) Can't find resource for bundle java.util.PropertyResourceBundle, key ERROR_DUPLI CATE_WEB_INF_LIB ERROR_DUPLICATE_WEB_INF_LIB Can't find resource for bundle java.util.PropertyResourceBundle, key ERROR_DUPLI CATE_WEB_INF_LIB ERROR_DUPLICATE_WEB_INF_LIB Thread[Java indexing,4,main] 1 awaiting jobs Thread[Java indexing,4,main] STARTING background job - indexing /DevNew/src/rubi
Ok, I can now confirm that it is saving a file that is causing the problem. In the console I did a search for references, everything was fine (returned expected number of references). I then made a change to a file, saved it and witness this exception in the console: Thread[Java indexing,4,main] -> got the following exception while saving: java.io.IOException: Failed to rename index file C:\Users\brettw\EclipseWorkspac es\farmconnectWorkspaceIndigo\.metadata\.plugins\org.eclipse.jdt.core\1589233677 .index at org.eclipse.jdt.internal.core.index.DiskIndex.mergeWith(DiskIndex.jav a:560) at org.eclipse.jdt.internal.core.index.Index.save(Index.java:192) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndex( IndexManager.java:774) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.saveIndexe s(IndexManager.java:816) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.notifyIdle (IndexManager.java:546) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:388) at java.lang.Thread.run(Unknown Source) I then performed the same search for references and it returned 0 references. Brett
I can also confirm that the index file in question has for some reason been deleted. I kept an explorer window open and observed the index file list and could see an index file being updated whenever I saved a file and everything was functioning correctly. 15 mins later the above mentioned exception occurred and I noticed the index file mentioned in the exception had been deleted. Brett
More analysis: Actually, the index file has not been deleted. It has been renamed to <number>.index.tmp. If I rename the file back to <number>.index the exception is cleared and eclipse functions normally for around 10 - 15 mins use and then the file is renamed back to <number>.index.tmp. Brett
Ayush, please take a look.
I will look at this. BTW, which version of Eclipse are you using?
"Fast service, no matter how long it takes". The original date on this report was 2005. The best I can say is I was probably using the version of eclipse that was current at the time.
Great thanks. I'm on Version: Indigo Release Build id: 20110317-0634 But please note that I have seen the same thing on Helios. Brett
(In reply to comment #55) > More analysis: > Actually, the index file has not been deleted. It has been renamed to > <number>.index.tmp. If I rename the file back to <number>.index the exception > is cleared and eclipse functions normally for around 10 - 15 mins use and then > the file is renamed back to <number>.index.tmp. > Brett Thanks for your analysis: The problem seems to be arising because File#renameTo() is not working in come cases. Which version of JRE are you using? Are you using any specific file system? FYI, here is a short description of what happens with index files. Eclipse periodically saves the updated index files onto the disk. To save it first writes into a file called <filename>.index.tmp, then deletes the original file <filename>.index and then renames the <filename>.index.tmp to <filename>.index. The probable way to fix this could be is to repeatedly try renaming for a while! Let me explore further.
>To save it first writes into a file called <filename>.index.tmp, Do we ever use the tmp file? If not, we could drop that logic. >The problem seems to be arising because >File#renameTo() is not working in come cases. File deletion can be delayed on some systems if the file was opened before (or especially if it wasn't closed before). >The probable way to fix this could be is to repeatedly try renaming for a >while! Let me explore further. Do we have to reuse the filename (index number)? If not, a faster approach would be to simply use the next non-existent filename (index number).
(In reply to comment #61) > >To save it first writes into a file called <filename>.index.tmp, > Do we ever use the tmp file? If not, we could drop that logic. The file writing is just not an append. The file needs to be completely rewritten and hence, I think it is better to first write into a temporary file rather than modify the original file directly. > > >The problem seems to be arising because > >File#renameTo() is not working in come cases. > File deletion can be delayed on some systems if the file was opened before (or > especially if it wasn't closed before). The files are being generally closed immediately after the reads. > >The probable way to fix this could be is to repeatedly try renaming for a > >while! Let me explore further. > Do we have to reuse the filename (index number)? If not, a faster approach > would be to simply use the next non-existent filename (index number). The index numbers are the CRC code of the file paths. They are used to map the index file name to the file paths that is being indexed. Hence, we cannot use another index number.
(In reply to comment #62) > (In reply to comment #61) > > >To save it first writes into a file called <filename>.index.tmp, > > Do we ever use the tmp file? If not, we could drop that logic. > The file writing is just not an append. The file needs to be completely > rewritten and hence, I think it is better to first write into a temporary file > rather than modify the original file directly. But it only makes sense if there's some fallback code in case writing or renaming fails. If not, we could simply write to the file.
There's a class of problem caused by interaction with real-time antivirus and/or backup software. If one of these "background" processes has a file open, it can cause mundane operations such as delete or rename to fail. Perhaps this is what's going on here.
(In reply to comment #60) > Thanks for your analysis: The problem seems to be arising because > File#renameTo() is not working in come cases. Which version of JRE are you > using? Are you using any specific file system? > FYI, here is a short description of what happens with index files. Eclipse > periodically saves the updated index files onto the disk. To save it first > writes into a file called <filename>.index.tmp, then deletes the original file > <filename>.index and then renames the <filename>.index.tmp to <filename>.index. > The probable way to fix this could be is to repeatedly try renaming for a > while! Let me explore further. I'm using JRE1.6.0_23, no specific file system (I'm using a 64 bit machine running Windows 7). I'll keep an eye on my task manager today to see if there are any background processes running when it happens (just to check Dave's antivirus theory).
(In reply to comment #63) > (In reply to comment #62) > > (In reply to comment #61) > > > >To save it first writes into a file called <filename>.index.tmp, > > > Do we ever use the tmp file? If not, we could drop that logic. > > The file writing is just not an append. The file needs to be completely > > rewritten and hence, I think it is better to first write into a temporary file > > rather than modify the original file directly. > But it only makes sense if there's some fallback code in case writing or > renaming fails. If not, we could simply write to the file. There is some fallback if writing goes bad.
(In reply to comment #66) > (In reply to comment #63) > > (In reply to comment #62) > > > (In reply to comment #61) > > > > >To save it first writes into a file called <filename>.index.tmp, > > > > Do we ever use the tmp file? If not, we could drop that logic. > > > The file writing is just not an append. The file needs to be completely > > > rewritten and hence, I think it is better to first write into a temporary file > > > rather than modify the original file directly. > > But it only makes sense if there's some fallback code in case writing or > > renaming fails. If not, we could simply write to the file. > There is some fallback if writing goes bad. k. I guess even if we tried to write directly, it would be blocked when the file is locked by some other thread. Maybe instead of re-trying several times immediately, we could continue with the other files and then retry at the very end (hoping that the file is no longer locked). Also, we should probably think of fallback solutions in case a file cannot be written as we can not retry indefinitely.
(In reply to comment #67) >Also, we should probably think of fallback solutions in case a file cannot be >written as we can not retry indefinitely. Sure, I will do that
Created attachment 198064 [details] Proposed patch In this patch, the failed rename operation is tried after two milliseconds and even if that fails the tmp file will be used for subsequent read operations. Whenever, a write is required, the original file will be attempted to be written. I am unable to write a test for this, though I could manually verify it while debugging.
Ayush, Can you please review?
Good news/Bad news guys. I have a workspace stuck in this state right now, and I've saved it for you. I am running a current build, 20100917-0705, but no patch. Also, there's no evidence from procmon of a problem renaming, and as a further test I shut off my antivirus and backup daemons. No difference. So the good news is that this is 100% reproducible. I have a simple procedure that goes from "no errors/no calls to this function" then when I change the name of the function, 7 errors pop up corresponding to the calls. Then when I rename the function back, the errors go away and the search/references still says zero. The bad news is that this workspace is a monster, almost 600 mb. I've complained elsewhere about the bloat associated with workspaces, but that's for another day.
(In reply to comment #71) > Good news/Bad news guys. I have a workspace stuck in this state > right now, and I've saved it for you. I am running a current > build, 20100917-0705, but no patch. > > Also, there's no evidence from procmon of a problem renaming, and as a further > test I shut off my antivirus and backup daemons. No difference. > > So the good news is that this is 100% reproducible. I have a simple > procedure that goes from "no errors/no calls to this function" then > when I change the name of the function, 7 errors pop up corresponding > to the calls. Then when I rename the function back, the errors go away > and the search/references still says zero. > > The bad news is that this workspace is a monster, almost 600 mb. I've > complained > elsewhere about the bloat associated with workspaces, but that's for another > day. The index files are typically kept in <workspace>/.metadata/.plugins/org.eclipse.jdt.core. Please back this up before you do anything :) Can you see how big this folder will be? How much will it be if you zip this folder?
5mb zipped for just this folder.
(In reply to comment #73) > 5mb zipped for just this folder. Can you please give this folder? Please add this to the bug attachment as a big file.
Created attachment 198784 [details] eclipse metadata folder with correupt references database The example function of interest is in class GameState funciton isSoloGame() there should be 7 callers, but are reported to be none.
Interesting other tidbits about the behavior of this workspace. I made a copy of the entire workspace - source, object and metadata - and opened this copy as a workspace. The copy does NOT exhibit the bug, so something in the rehashing that occurs as a consequence of copying the workspace seems to have denatured the bug. Meanwhile, the original workspace (which I haven't used since yesterday) still exhibits the bug. The machine has been rebooted. Its possible that my previous report that I turned off my background process may be incorrect. More later if I determine that is the case.
(In reply to comment #76) > Interesting other tidbits about the behavior of this workspace. I made > a copy of the entire workspace - source, object and metadata - and opened > this copy as a workspace. The copy does NOT exhibit the bug, so something > in the rehashing that occurs as a consequence of copying the workspace seems > to have denatured the bug. Meanwhile, the original workspace (which I haven't > used since yesterday) still exhibits the bug. The machine has been rebooted. > > Its possible that my previous report that I turned off my background > process may be incorrect. More later if I determine that is the case. Just to confirm, you are saying that restart of the eclipse is not fixing the problem - right? The index files are generally recreated if the workspace is moved. Hence the copy may not exhibit the bug. Can you also give the index files of the workspace that is working?
restarting eclipse does not fix the problem rebooting the machine does not fix the problem "clean" on the workspace does not fix the problem. copying the workspace and opening the copy in a new location fixes the problem.
Created attachment 198788 [details] same metadata, but from a copied and reopened workspace It seems odd that moving the workspace does something to clean up the workspace that "clean" does not.
(In reply to comment #79) > Created attachment 198788 [details] > same metadata, but from a copied and reopened workspace > > It seems odd that moving the workspace does something to clean up > the workspace that "clean" does not. They are unexpected class files in the index. Is this particular project's source folder is a class folder for another project? Can I have the classpath's of the project's involved? I still don't have a proper reasoning for this particular problem. The indexes do contain the information that the method isSoloGame() is being referred from GameState.java, Marketplace.java and MainWindow.java and ofcourse their class files. How do you do the search, "Search for references in the project/workspace/??).
yes, click right on "references" select "workspace" also, note that the function isSoloGame isn't unique. It appears that the entire folder "lehavre" within the workspace is returning "none found" The project within the workspace has over 40 folders. I will upload the .classpath
Here is the relevant .classpath <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry combineaccessrules="false" kind="src" path="/jzlib"/> <classpathentry kind="lib" path="G:/share/projects/eclipse/jzlib.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6"/> <classpathentry kind="output" path="bin"/> </classpath>
(In reply to comment #81) > yes, click right on "references" select "workspace" > > also, note that the function isSoloGame isn't unique. It appears that > the entire folder "lehavre" within the workspace is returning "none found" I do see indexes for class files of the lehavre folder and that could be the reason. Is any other project depending on the lehavre folder of this project? Are there class files in the lehavre source folder? It may help if you could give the classpath(s) of the other projects too. I will try to create a similar workspace from my end. Is by any chance the name of the project for the classpath you had given is jzlib? Is it right that you don't see the problem in fresh workspaces but do see the problem once you rename or do some modification?
jzlib is one of the projects in the workspace, but not the active one. undefined perturbations of the workspace clear the problem, including renaming the workspace.
nothing external depends on or references anything in the lehavre folder. it's linked to the workspace only by implementing some common interfaces.
(In reply to comment #85) > nothing external depends on or references anything in the > lehavre folder. it's linked to the workspace only by implementing > some common interfaces. Can you please give the classpath(s) of all the projects? I want to try to reproduce the problem here.
There are 5 projects in the workspace. //boardspace <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry combineaccessrules="false" kind="src" path="/jzlib"/> <classpathentry kind="lib" path="G:/share/projects/eclipse/jzlib.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6"/> <classpathentry kind="output" path="bin"/> </classpath> //download <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/> <classpathentry kind="lib" path="C:/java/mysql-connector-java-5.1.10/mysql-connector-java-5.1.10-bin.jar"/> <classpathentry kind="output" path="bin"/> </classpath> //jzlib <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6"/> <classpathentry kind="output" path="bin"/> </classpath> //tantrix <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry combineaccessrules="false" kind="src" path="/jzlib"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6"/> <classpathentry kind="output" path="bin"/> </classpath> //utf8 <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry excluding="chinese-java-sample.gif|chineseStrings.original|chineseStrings.utf8|chineseStrings1.xjava|japanese-discovery-sample.gif|japanese-lobby-sample.gif|japaneseStirngs.rtf|japaneseStrings.class|japaneseStrings.java|japaneseStrings.out|japaneseStrings.rtf|japaneseStrings.utf8|japaneseStrings.utf8x|japanesepuzzle.utf8.html|koreanStrings.class|koreanStrings.java|koreanStrings.original|koreanStrings.utf8|norwegian-sample-glaphic.jpg|norwegianstrings.out|norwegianstrings.rtf|norwegianstrings.utf8|polish.java.html|polish.utf8|sample_data.js|utf8.kawa" kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6"/> <classpathentry combineaccessrules="false" kind="src" path="/boardspace"/> <classpathentry kind="output" path=""/> </classpath>
If you plan to include a fix for this in 3.8 M7, please adjust the target suitably, so it becomes easier to track.
Just wanted to confirm this problem exist on indigo, windows 7, x64 aswell. By deleting the cached info as described in the comments from back in 2005 I managed to get it sorted. Eclipse Java EE IDE for Web Developers. Version: Indigo Release Build id: 20110615-0604
Experienced a case in which "occurrences in workspace" is wrong: it doesn't see references for a protected method, but during the compilation the errors (and so the references) come to light. Eclipse Indigo on Ubuntu 11.04 "Natty Narwhal" 32 bit.
(In reply to comment #42) > (In reply to comment #34) > > ... > > So, if there are any logging settings or suggestions I can try, I'm happy to > > use the guys here as guinea pigs to see what we can find out. > > ... > You can set debug options for the indexing: > 1) create or modify the .options file in the <install dir>/eclipse directory > by > adding the following lines: > > # Turn on debug tracing for org.eclipse.jdt.core plugin > org.eclipse.jdt.core/debug=true > > # Reports background indexer activity: indexing, saving index file, index > queries > org.eclipse.jdt.core/debug/indexmanager=true > > 2) add -debug and -consoleLog to the command line while launching eclipse > 3) then, IMMEDIATELY after the problem occurs, copy all the contents > displayed in > the DOS Window Eclipse console, paste it into a file and attach this file > to > this bug. > > TIA I turned on debugging and it looks like eclipse successfully found the subclasses classes but did not list them on the UI: Thread[ModalContext,6,main] STARTING concurrent job - searching SuperClassReferencePattern: <AbstractClass>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] -> execution time: 33ms - searching SuperClassReferencePattern: <AbstractClass>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] FINISHED concurrent job - searching SuperClassReferencePattern: <AbstractClass>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] STARTING concurrent job - searching SuperClassReferencePattern: <Subclass1>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] -> execution time: 2ms - searching SuperClassReferencePattern: <Subclass1>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] FINISHED concurrent job - searching SuperClassReferencePattern: <Subclass1>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] STARTING concurrent job - searching SuperClassReferencePattern: <Subclass2>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] -> execution time: 0ms - searching SuperClassReferencePattern: <Subclass2>, exact match, case sensitive, generic full match, fine grain: none Thread[ModalContext,6,main] FINISHED concurrent job - searching SuperClassReferencePattern: <Subclass2>, exact match, case sensitive, generic full match, fine grain: none This was with a brand new eclipse install, workspace and project files. All classes were part of the same project though they depended on an interface exported from another project.
(In reply to comment #91) > (In reply to comment #42) > > (In reply to comment #34) > > > ... > I turned on debugging and it looks like eclipse successfully found the > subclasses classes but did not list them on the UI: Thanks for the additional details. Unfortunately Satyam is no longer an active committer to JDT/Core. Going through the history of the bug, looks like we had trouble reproducing the bug in our environment. Markus, do you think the last comment has enough information to suggest whether the issue could be on the UI side or otherwise?
This problem still exists in the latest public build, Version: 4.2.2 Build id: M20130204-1200 I have a case right now where the reference count is demonstrably incorrect.
(In reply to comment #93) > This problem still exists in the latest public build, > Version: 4.2.2 > Build id: M20130204-1200 > > I have a case right now where the reference count is demonstrably incorrect. Could you share more information, please?
It's essentially the same as described in all the previous traffic - "show references" shows a list that is demonstrably incomplete. I've saved the metadata for the workspace in question. If someone is willing to work on it, I'll take the trouble to upload it and/or provide additional assistance.
(In reply to comment #95) > If someone is willing to work on > it, I'll take the trouble to upload it and/or provide additional assistance. I would say it's unlikely until Java 8 work is complete. Definitely not for 4.3. Assigning to Manoj as he is going to be the owner for search and indexing.
(In reply to comment #96) > (In reply to comment #95) > > If someone is willing to work on > > it, I'll take the trouble to upload it and/or provide additional assistance. > > I would say it's unlikely until Java 8 work is complete. Definitely not for > 4.3. > > Assigning to Manoj as he is going to be the owner for search and indexing. If Dave has a workspace, where we can see the problem, then it is worth being looked at right now.
The full workspace is over a gigabyte and involves a lot of proprietary code, but just the metadata is a mere 40 megabytes. Previous discussion about this bug led me to believe that there is an inconsistency in the cached information, and that the real bug is somewhere in the cache maintenance, which could be very hard to find. A simpler partial fix would be to clear the cache more aggressively, including at least clearing it as part of clean and rebuild.
As Frederic already discovered in comment 17 & comment 25, the problem seems to be a corrupt index, but nobody knows why and when it got corrupted. Comment 62 has a theory of the problem and explains why moving/renaming the workspace can fix the problems ("The index numbers are the CRC code of the file paths."). Comment 69 even has a proposed patch. I'm not sure if we really need more info/workspaces at this time; especially, since nobody is working on it right away.
And I am seeing it now, in oct. 2013. Reported in 2005. This bug affects several core features of Eclipse: * Search references * Refactor (as it depends on finding references) * Show type hierarchy * Open Type These are very important features. They are what makes Eclipse a powerful editor in the first place, but if we can't trust them, they quickly lose their value to the point where we just go back to text search, just renaming and fixing compile errors etc. This bug is more important that Windows 8 work! Also, why is this bug marked as NEW? How many confirmations does a bug need to get it's status promoted to CONFIRMED? Every new committer looking at this bug starts out working from the assumption that it might not actually be a bug, when it clearly is. I know Eclipse is free software and I thank you all for it, but even just using it and certainly taking the trouble to file bug reports on it also represents an investment from our side. Please give us at least the acknowledgement that this indeed is a bug by setting it's status to confirmed. So, fixing it is hard. Why can't we make that easier then? * Hook deleting and rebuilding the indexes to the clean command. That gives users having this issue a less painful way to get rid of it (for a while). The code is already there as mentioned in comment #76 so just also hook it up to the clean command. * Add logging! Adding logging statements is fairly easy and won't hurt. Just log on DEBUG level and ask everyone that reports an issue related to this to turn on debug logging and submit the log file. Each time a log file is sent, analyze it and if it still does not give enough info, add more logging. It may take some time, but eventually you will find the issue this way. It won't take 8 years, that's for sure.
Oh, and keyword 'needsinfo' should be removed as per Markus' conclusion: "Comment 69 even has a proposed patch. I'm not sure if we really need more info/workspaces at this time; especially, since nobody is working on it right away." Currently, all the meta indicators on this bug are saying it is unsure whether it is a bug and that there is no point in looking at it as there is not enough info... We need keyword 'needsattention' :p
Occurred for me on Kepler SR1 on Windows 7 64-bit. Restarting the workspace did not resolve the issue. Deleting the index files and restarting did resolve the issue.
(In reply to Dave Latham from comment #102) > Occurred for me on Kepler SR1 on Windows 7 64-bit. Restarting the workspace > did not resolve the issue. Deleting the index files and restarting did > resolve the issue. Do you have a back of the index files, by any chance? I am working with Dave (Dyer) to get this reproduced. If you hit upon this issue in future, please save the index files.
(In reply to Manoj Palat from comment #103) > Do you have a back of the index files, by any chance? ^^^^^ I meant backup/copy of the index files when the problem occurred?
moving to 4.5; yet to make progress here.
Hi, I just ran into this on my workspace. Agreed with previous comments that it's a fairly major (albeit rare) issue. Remarkably old bug!! Back to using text search for me... Synced from perforce (outside editor), hit 'refresh'. I do this daily (and have been for years) but today it decided to explode. Find all references works on some things but not others with the same behaviour as described above. Restarting actually caused it to change which things it worked on, but still overall it is not working on a lot of references. Deleted *.index and savedIndexNames.txt and it seems fine again. I saved a copy of my metadata directory if that would help you debug the problem.
(In reply to Jesse Attard from comment #106) > Hi, > > Deleted *.index and savedIndexNames.txt and it seems fine again. I saved a > copy of my metadata directory if that would help you debug the problem. Jesse: Thanks for saving the data. Could you please upload these files/metadata directory? If it is big/private please send via email to me directly. We did take a look at this issue multiple times (by multiple people including me) but not with much success. Planning to work on this post M1 - At the least planning to increase the number of debug messages so as to nail down this issue.
Created attachment 245597 [details] Metadata directory when situation occurred
Hi Manoj, I uploaded the metadata directory - you don't need source files right?
(In reply to Jesse Attard from comment #109) > Hi Manoj, > > I uploaded the metadata directory - you don't need source files right? Jesse: Source files not required at this stage but would require the following info: 1. Details of the Type searched for 2. When the error occurred, a) instances found b)instances missed out Once you let me the answer to 1 I can check further and probably ask you only the relevant details pertaining to that type.
(In reply to Manoj Palat from comment #110) > (In reply to Jesse Attard from comment #109) > > Hi Manoj, > > > > I uploaded the metadata directory - you don't need source files right? > > Jesse: Source files not required at this stage but would require the > following info: > 1. Details of the Type searched for > 2. When the error occurred, a) instances found b)instances missed out > > Once you let me the answer to 1 I can check further and probably ask you > only the relevant details pertaining to that type. Manoj, 1. Definitely the first case was transientShadowMapBaked which is a boolean member variable inside Light.java. I do recall that upon restarting Eclipse this variable started working but a different one broke... (don't remember what the other one was). Can't recall if this meta-data was copied before or after I restarted Eclipse. 2. 0 instances were found, yet there are 6 references (all right in the same file - Light.java) Let me know if this helps.
(In reply to Jesse Attard from comment #111) > 1. Definitely the first case was transientShadowMapBaked which is a boolean > member variable inside Light.java. I do recall that upon restarting Eclipse > this variable started working but a different one broke... (don't remember > what the other one was). Can't recall if this meta-data was copied before or > after I restarted Eclipse. > > > Let me know if this helps. Jesse: From analysing the relevant index file for the "transientShadowMapBaked" in question, I don't see any corruption (for this case atleast). The index file says that this variable can be found at "GameClient/Base/Light.java" which I conclude as the same file you mentioned as "Light.java".
Guys, Just to let you know, this problem went away for me after I had my workspace directory excluded from the company's antivirus task, as pointed out by Dave Dyer in 2011. Sorry I didn't post earlier. Thanks a lot Dave. Brett
I'm still watching and waiting. Congratulations on successfully picking my relevant observation out of the flood of traffic on this oldie but goodie. Is there a prize for the longest outstanding bug, finally fixed? We got 10 years here!
(In reply to Manoj Palat from comment #112) > (In reply to Jesse Attard from comment #111) > > > > 1. Definitely the first case was transientShadowMapBaked which is a boolean > > member variable inside Light.java. I do recall that upon restarting Eclipse > > this variable started working but a different one broke... (don't remember > > what the other one was). Can't recall if this meta-data was copied before or > > after I restarted Eclipse. > > > > > > Let me know if this helps. > > Jesse: From analysing the relevant index file for the > "transientShadowMapBaked" in question, I don't see any corruption (for this > case atleast). The index file says that this variable can be found at > "GameClient/Base/Light.java" which I conclude as the same file you mentioned > as "Light.java". The meta-data must have been copied after I restarted Eclipse (which sounds correct now that I think about it). Unfortunately I just can't accurately remember the variable I looked for after I restarted. Sorry :(. I don't run anti-virus software on my machine so that is not the culprit in my case. Definitely it was syncing + refreshing from perforce.
Manoj, please read comment 99 and comment 69 again. Did you try to reproduce while manually locking the index file that should be updated? You can e.g. use java.nio.channels.FileChannel#lock() to lock the file. But note that this must be done from a separate JVM, since these locks are per-process (i.e. shared inside a JVM).
(In reply to Markus Keller from comment #116) > Manoj, please read comment 99 and comment 69 again. > > Did you try to reproduce while manually locking the index file that should > be updated? You can e.g. use java.nio.channels.FileChannel#lock() to lock > the file. But note that this must be done from a separate JVM, since these > locks are per-process (i.e. shared inside a JVM). Markus: Satyam already has a patch for this and I've modified the same to make it to apply to the latest code base. I will apply this patch post M1. This rename issue is a possibility and hence would apply this patch. However, from the rest of the comments I believe there is more than that issue at hand -Theory is either a) possible data race while accessing the index file b) data corruption due to some interruption while writing the index file or c) incorrect writing of the index file.
(In reply to Manoj Palat from comment #117) > > Markus: Satyam already has a patch for this and I've modified the same to > make it to apply to the latest code base. I will apply this patch post M1. > This rename issue is a possibility and hence would apply this patch. On second thoughts, decided to push this fix for M1 itself so that issues if any can be caught early. Rename issue fixed via commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=93bc0d951e48394510778784a6576e0cbdd0b011 Jay:need to include this fix for review for 4.5 M1
(In reply to Manoj Palat from comment #118) > Jay:need to include this fix for review for 4.5 M1 I see this has already been released. Did you mean 'verification'?
(In reply to Jayaprakash Arthanareeswaran from comment #119) > (In reply to Manoj Palat from comment #118) > > Jay:need to include this fix for review for 4.5 M1 > > I see this has already been released. Did you mean 'verification'? yes - verification
Moving this out of 4.5. Refer comment 118 for a fix for one of the issues. There are other possibilities as mentioned in comment 117 which at this point are still theories and don't have a reproducible test case with them.
Having the same problem, my solution is to delete the whole directory an let Eclipse rebuild everything. Following is just a guess, but maybe not that wrong: For me it looks like the problem occurs (mainly) in copied/renamed workspaces (which I do freqently). In savedIndexNames.txt the first line contains the absolute path to 'itself' (where the indices are stored) - shouldn't that be workspace-relative (.metdata/.plugins/org...) ? Now, if any part of Eclipse takes that path without 'correcting' it (make it relative to the new workspace-directory), references in current workspace won't be updated and the indices in the 'old' (form where I copied) get corrupted ...
This is still a problem with Eclipse 2020-06 (4.16). I don't know what triggers it, but find references in workspace breaks. It shows no matches, except potential matches which are often not what I need. Deleting the entire "workspace/.metadata/.plugins/org.eclipse.jdt.core" folder is necessary. I tried "rm *.index savedIndexNames.txt" but it was not enough. One thing I do often (a few times per day) is switch multiple git repositories to a different branch. This of course requires Eclipse to recompile everything, often complaining about all kinds of errors until it's done. When it is done everything compiles and works, but it may be triggering this issue. Also note sometimes a project exists in one branch and not the other. I'll keep an eye out to see if switching branches correlates to this issue occurring.
I verified it happens without any Git branch switching. It's not clear what triggers it, especially since now even deleting "workspace/.metadata/.plugins/org.eclipse.jdt.core" doesn't fix it. My find references finds only potential matches. Refactoring is also broken, eg renaming a method will say "there are potential matches, click Continue to review", but Continue does not review, it completes the refactoring using potential matches. If I rename a method like getName, it'll rename a ton (but not all) of getName methods in my projects. As a (terrible) workaround I can type XXX in a method name, then look at compiler errors to see where the method was called. There is no workaround for broken refactoring though. This puts a serious damper on my productivity, so much that I'm considering changing IDEs after being a faithful Eclipse user for 17 years. Please let me know how I can help debug this problem or provide more information.
Some progress: I discovered the problem only occurs with a specific JRE that has been through jlink. If I use the full JDK then search works. Note with the jlinked JRE my apps run, can be debugged, and everything works except references search. Could it be some specific module is needed for search to work? The modules I'm passing to jlink are: jdk.localedata,java.prefs,jdk.unsupported,java.desktop,java.instrument,java.logging,java.rmi,java.security.sasl,java.naming,java.management,java.management.rmi,jdk.management,jdk.management.agent,java.compiler,jdk.jdwp.agent At any rate, at least I'm unblocked now (though I have to use a JRE that has more on the classpath than what will be in production).
This bug seems still to be present in Eclipse 2022-09 (4.25.0) Build id: 20220908-1902. It happened to me in earlier versions, too, from time to time. The only workaround for me at the moment is to use normal textsearch in such a case which naturally finds all the references I am expecting. The "Reference search" on the other hand, does not yield all results. Tried re-indexing, restarting eclipse, rebuilding the whole workspace - nothing helps.
