Community
Participate
Working Groups
Created attachment 129690 [details] messagebox that shows an wrong info (because the file exists AND the full Workspace is Refreshed) Build ID: M20090211-1700 Steps To Reproduce: 1.Open Type 2.Select an class 3. OK More information:
Cannot reproduce using 3.5 M6. Sorry, but there's not enough information for us here. See also: http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm One thing that could be is that one of your referenced external JARs is out of sync and you used the Project Explorer instead of the Package Explorer to refresh. I suggest you go to the Package Explorer, select all projects and then press F5 and try again.
I already (and often) have Refreshed all Projects in the PackageExplorer (i use only this) and i have often this failure - since maybe 1 month. AND in my work more collegues have the same problem - every day and also since short time, although we use eclipse 3.4 surely since many month. What can i do to help you to find the problem?
Can you provide a test case / steps?
testcase: how can i do? i only select OpenType and i type some parts of an classname that i whant to open and then i doubleclick that class and this message appears..
>testcase: how can i do? Provide steps that start with a fresh drop and a fresh workspace or send us your workspace so that we can reproduce.
is there no chance to set/activate better logging and to provide this to you? my eclipse installation is older and updated von 3.4 -> 3.4.1 -> 3.4.2 and with many plugins, so the exact redoing would be expensive. my workspace is big (more than 10 projects, each between 10 000 and 200 000 loc), so i cant easily reproduce and i surely not allowed to give the source to you.
today i get a new problem with OpenType: (see screenshot) and in the .log i get: !ENTRY org.eclipse.core.jobs 4 2 2009-03-25 08:56:01.871 !MESSAGE An internal error occurred during: "Items filtering". !STACK 0 java.lang.IllegalArgumentException: Class file name must end with .class at org.eclipse.jdt.internal.core.PackageFragment.getClassFile(PackageFragment.java:182) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.createTypeFromJar(TypeNameMatchRequestorWrapper.java:146) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.acceptType(TypeNameMatchRequestorWrapper.java:108) at org.eclipse.jdt.internal.core.search.BasicSearchEngine$2.acceptIndexMatch(BasicSearchEngine.java:779) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.acceptMatch(InternalSearchPattern.java:47) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.findIndexMatches(InternalSearchPattern.java:88) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:269) at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:97) at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:63) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:276) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:790) at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:815) at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.fillContentProvider(FilteredTypesSelectionDialog.java:553) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:2175) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.internalRun(FilteredItemsSelectionDialog.java:2117) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.doRun(FilteredItemsSelectionDialog.java:2089) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.run(FilteredItemsSelectionDialog.java:2076) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Created attachment 129811 [details] comment to this picture above
>!STACK 0 >java.lang.IllegalArgumentException: Class file name must end with .class Strange. Do you have some additional tooling installed that could cause this? Please delete your search index: <workspace>.metadata\.plugins\org.eclipse.jdt.core\*.index <workspace>.metadata\.plugins\org.eclipse.jdt.core\savedIndexNames.txt and try again. Does it now work? If not, does Java Search find the "broken" types?
After Deleting the given files and restarting Eclipse the new failure (that i reported this day) is away. Thank you! The old (original failure) is still there. Some classes will be found an opened and some not.. A class that i find in OpenType, but cant open can be found in the javaSearch (i used the options Type and Declarations). Although i already opened that File, it cant be opened with the OpenType-Search - with the known message (screenshot1).
Maybe the type appears twice in the dialog? Do you select from the remembered items (above the line --- Workspace matches ---) or below? If they are above, select them all and then context menu > Remove from History
Thank you. Now it works for me. My collegue has the same problem furthermore, after deleting the files im metadata and restart and refresh of projects and openType->removeHistory. what could be done?
Strange. Are you sure you remove all items that were cached? Anything in .log?
I have today done the same actions to solve the problem on an computer of one another collegue and there it also helped! The collegue right of me, where this does not helped yesterday, will replace his whole eclipse-installation be mine and so we hope that this problem will also be history. Thank you for your affort. I hope it is possible to make an correction in 3.5 that such problems will not occur in future...
>I hope it is possible to make an correction in 3.5 that such problems will not >occur in future... The problem is that we don't have a test case. If your colleagues workspace is still broken we could debug it. Moving to JDT Core to take a look on how this could happen. Frédéric, is there something we can debug?
(In reply to comment #15) > >I hope it is possible to make an correction in 3.5 that such problems will not > >occur in future... > The problem is that we don't have a test case. If your colleagues workspace is > still broken we could debug it. > > Moving to JDT Core to take a look on how this could happen. > > Frédéric, is there something we can debug? > Unfortunately no... We already got it with the debugger and have some clues on the origin of the problem, but when this symptom happens, this is too late. We suspect the problem to happen when a re-indexing occurs, but it's hard to track as we currently cannot find any test case to reproduce it. Remove all the indexes files is definitely the best workaround which can be applied to solve this problem and hopefully should fix it for a long time in the workspace... Set as duplicate of bug 268933 which already tracks this issue... *** This bug has been marked as a duplicate of bug 268933 ***
in the past weeks the problem comes again more often - although i have redone the tips (index files delete in the workspace and remove from openType history). now i realized that it was partly better - but not solved - as i have deselected an workingset and additionally selected a new filter of files in the openType dialog configuration. i and many of my collegues have daily real problems with that issue. we now use almost ever the open ressource dialog, but that is not an equal option.. is there now any new idea to help us?
(In reply to comment #17) > in the past weeks the problem comes again more often - although i have redone > the tips (index files delete in the workspace and remove from openType > history). > > now i realized that it was partly better - but not solved - as i have > deselected an workingset and additionally selected a new filter of files in the > openType dialog configuration. > > i and many of my collegues have daily real problems with that issue. > > we now use almost ever the open ressource dialog, but that is not an equal > option.. > > is there now any new idea to help us? > I guess you're still using 3.4.2 while encountering this issue. Would it be possible to open this workspace (or a copy of it) with 3.5RC4 and let us know if you get a similar issue with this newest version?
Thomas, are you (or your colleagues) still annoyed by this problem? Another idea if your workspace is a little bit old and if you cannot update to the new eclipse version 3.5.0 available in a few days. Then try to create a brand new workspace and import the projects of your old workspace in it...
a collegue of mine has tried it in the newest stable eclipse 3.5 and it is partly solved. without any active filter or workingset it is solved. with filter or workingset the problem is still there.
(In reply to comment #20) > a collegue of mine has tried it in the newest stable eclipse 3.5 and it is > partly solved. > without any active filter or workingset it is solved. > with filter or workingset the problem is still there. > Thomas, do you still observe the stack trace in the .log when getting this issue using filter or workingset? If so, would it be possible for me to remote debug or for you to debug it and let me know the full path of the jar file?
after reproducing the problem is no new entry in the .metadata/.log we can not remotely let you debug on our machines. how we can debug this problem and deliver you sufficient informations?
(In reply to comment #22) > after reproducing the problem is no new entry in the .metadata/.log > So, that mean you only get the problem described in comment 0: "Type '...' could not be found..." and you do no longer get the one described in comment 7. Is it correct?
that is correct.
OK, so as debug was only for comment 7 issue, forget my previous comment about this... However, we can try to setup some debug information. I propose the following test: 1) close your eclipse session 2) a) if you're already using the -debug <path to .options file> argument in your eclipse command line, then add/modify the following lines in the .options file: # 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 org.eclipse.jdt.core/debug/indexmanager/advanced=false # Reports java search activity org.eclipse.jdt.core/debug/search=true b) if you never use the -debug argument, then extract the .options file from the plugins/org.eclipse.jdt.core_3.5.0.v_963.jar file and put it in the <eclipse install dir>/eclipse directory. Modify the value of the properties as described in 2.a) Add the -debug argument to your eclipse command line 3) Remove all index files 4) Add the -consoleLog in your eclipse command line (if not already done) 5) Restart your eclipse session 6) Configure the console window to have the maximum of width (512) and height (9999). This can be done by clicking on the top-left corner and select the Properties item of the menu... 7) After the issue has occured again, go to the console window, copy all the output in the window, paste it in a file, zip the file and attach it to the bug If we're lucky then I could find any interesting clues in the index/search debug information (I cross the finger)
Created attachment 142118 [details] Log after starting eclipse like recommended This is the zipped console-output after starting eclipse like recommended and using OpenType. I hope it helps.
(In reply to comment #26) > Created an attachment (id=142118) [details] > Log after starting eclipse like recommended > > This is the zipped console-output after starting eclipse like recommended and > using OpenType. > I hope it helps. > Thanks, but unfortunately that does not help because it seems that the index files were not deleted, hence no indexing activity was noticeable in this output. Didn't you miss step 3)?
the console is greater 9999 lines und the windows-console-buffer cant be made greater (i think). so we dont be able to get the full content. is there an option to forward the output to a file?
(In reply to comment #28) > the console is greater 9999 lines und the windows-console-buffer cant be made > greater (i think). so we dont be able to get the full content. > is there an option to forward the output to a file? > Unfortunately no :-( But perhaps if you give the whole 9999 lines in the file may I found something interesting... (that's why I crossed my fingers!).
Created attachment 142216 [details] last 9999 lines of the console-log i hope it helps..
(In reply to comment #30) > Created an attachment (id=142216) [details] > last 9999 lines of the console-log > > i hope it helps.. > Unfortunately no... :-( The only solution I'm seeing now is to send you a patch to catch some additional information while this peculiar issue occurs... I'll send it to you soon
Closing as a duplicate of bug 286379. Try 3.6M3 and report if you still get this issue. *** This bug has been marked as a duplicate of bug 286379 ***
Please ReOpen, this Problem still occurs in Eclipse 3.6m6. I had postet this in https://bugs.eclipse.org/bugs/show_bug.cgi?id=286379 comment #39 and in many commetns from #4 on https://bugs.eclipse.org/bugs/show_bug.cgi?id=309127 this bug was closed as duplicate and then the other bug was fixed. but it seams to be not full fixed. the bug here still occurs (details you can find in bug 309127)
>Please ReOpen, Thomas, please simply open a new bug report with steps to reproduce as requested by Olivier.
(In reply to comment #33) > Please ReOpen, this Problem still occurs in Eclipse 3.6m6. > I had postet this in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=286379 > comment #39 > and > in many commetns from #4 on > https://bugs.eclipse.org/bugs/show_bug.cgi?id=309127 > > this bug was closed as duplicate and then the other bug was fixed. > but it seams to be not full fixed. > the bug here still occurs (details you can find in bug 309127) The problem reported in comment 7 has been fixed in bug 286379. The problem you described with a video in bug 309127 is different from this one. In bug 286379 comment 39, you mention a working set, but the bug report is about another issue. If you want us to focus on your problem, issues must be clearly explained and not mixed up with other unrelated issues. So as I said, open a new bug report so that we can start a new discussion and provide a test case (a small workspace) that defines different working sets that are leading to the search issue you are seeing.
