Summary: | Java search gives no results on workspace with multiple projects | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Paul Rädle <smail> | ||||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | critical | ||||||||
Priority: | P3 | CC: | frederic_fusier, philippe_mulet, smail | ||||||
Version: | 3.2.2 | ||||||||
Target Milestone: | 3.3 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 2000 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Paul Rädle
2007-04-12 11:45:34 EDT
I'll investigate this one. I would need to name of the jar on which the indexer crashed. If you can reproduce it all the time, would you use a patch version of JDT/Core that would log the jar name? If yes, I can prepare it immediately. Thanks for your help. Released some logging when the indexer crashes to find out on what jar is crashed. Paul, Could you please try next week integration build that will contain some logging in case this occurs again? Once I get the name of the jar that leads to this error, I should be able to address the defect. Thanks for your help. Paul, Did you reproduce it using this week integration build ? I added some tracing to know what jar file is causing the failure. Created attachment 65020 [details]
classes that cause the crash
Oliver, Today I found the time to check it with the integrational build. And yes - it also happend. Thank's to your additional logging the binary that caused the crash could be identified. Some very old class files from our 3rd-Party-directory we actually do not use any more caused the crash. These class files are still in our central directory and are therefore still found in the classpath. After removing the files everything worked. Thanks a lot!!! You should be able to reproduce the problem by adding the classes-directory from the unpacked attachment to a build path as a library. I did it using a link. (Apart from that - maybe its makes sense to do the indexing less sensitive?, i.E. leaving out files that cause crashes and only reporting the errors? Just an idea.) So thanks again for your help. This was a fast response. Happy to use Eclipse! Best regards, Paul Rädle --- Error log --- eclipse.buildId=I20070424-0930 java.version=1.5.0_07 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Framework arguments: -startup E:\EclipseIntegration\eclipse\plugins\org.eclipse.equinox.launcher_1.0.0.v20070423.jar Command-line arguments: -os win32 -ws win32 -arch x86 -startup E:\EclipseIntegration\eclipse\plugins\org.eclipse.equinox.launcher_1.0.0.v20070423.jar !ENTRY org.eclipse.jdt.core 4 4 2007-04-26 13:58:41.170 !MESSAGE Indexer crashed on document /TradeMachine_MATM/3rdParty/com/symantec/itools/awt/CurrencyTextField.class !STACK 0 java.lang.ArrayIndexOutOfBoundsException: 32905 at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.extractName(BinaryIndexer.java:535) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.extractReferenceFromConstantPool(BinaryIndexer.java:568) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.indexDocument(BinaryIndexer.java:749) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:74) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:314) at org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:658) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:392) at java.lang.Thread.run(Thread.java:595) I'll investigate. Thanks for your help. >(Apart from that - maybe its makes sense to do the indexing less sensitive?,
>i.E. leaving out files that cause crashes and only reporting the errors? Just
>an idea.)
You are right.
I'll try to improve our robustness in the binary indexer. We should not crash if we cannot index a jar, but we should log it for investigation.
My guess in your case is that these .class files have been obfuscated.
One entry in the constant pool of one of the class in the zip seems to be corrupted. We crash and we should be more resilient. javap found the same error: const #42 = Method #4.#209; // com/symantec/itools/swing/CurrencyEngine.<invalid constant pool index:32905>:(I)V So we need to be more resilient and allow the indexing of the rest of the jar file since only this entry is boggus. Now we need to decide if we want to skip the whole .class file from the indexing or if we want to index as much as possible. My concern is to slow down the indexer to support boggus .class files. I would simply skip the whole class and move to the next one to index. Philippe or Frédéric, Any comment on this ? (In reply to comment #11) > Now we need to decide if we want to skip the whole .class file from the > indexing or if we want to index as much as possible. > My concern is to slow down the indexer to support boggus .class files. > > I would simply skip the whole class and move to the next one to index. > I agree, we should keep performance as best as we can, especially in this sensible area. Invalid class files are not so frequent, so I definitely vote +1 to skip the file in this case... The fix is then to not propagate the RuntimeException in the logging I added for last build. Now I get: Indexer crashed on document D:/Downloads/IndexerCrashFiles.jar|classes/com/symantec/itools/awt/CurrencyTextField.class But the search is not failing anymore. This would make the binary indexer more resilient to boggus .class files. We are still logging the error since we might want to debug the test to be sure we are not hiding a bug in the binary indexer. I will NLS'd the error string and recommend to report the problem against JDT/Core. How does this sound ? Created attachment 65043 [details]
Proposed fix
Released for 3.3M7. The document that cannot be indexed is skipped and all entries already recorded for the document are removed. The indexer should then process to the next entry. In order to verify, use the attached zip file on the classpath of a project. Verified for 3.3 M7 using build I20070427-0010. |