Community
Participate
Working Groups
Build 20020416 Linux-Motif IBM 1.3.1 VM This started with the 20020414 build. I created a workspace and all was going well for almost two days. Then I chose to do a "rebuild all" for the first time and Eclipse completely vanished out of nowhere. The bug has continued with the 20020416 build. Every single time I select "rebuild all" on IBM 1.3.1 Eclipse completely dies. I've verified that this doesn't happen on JDK 1.4.
Created attachment 620 [details] javacore.txt - the java core file generated when the VM crashes
This also occurs on Win2k with IBM JDK 1.3.1.
Created attachment 622 [details] javacore.20020416.171350.948.txt
When I try this with Sun's 1.4.1 Beta VM, I get the following printout to the console, but the workspace does come up. Unable to restore mru list - cannot instantiate input element: org.eclipse.jdt.u i.ClassFileEditorInputFactory Unable to restore mru list - cannot instantiate input element: org.eclipse.jdt.u i.ClassFileEditorInputFactory Workspace zip available upon request (~20M).
Could you make your win workspace available to us for reproducing this defect ?
Can you also try to reproduce on IBM jre 1.3.1 with jit disabled ?
I ran with the -classic argument and encountered a crash. The following is what was printed to the console. A dialog came up that said: The instruction at "0x71b57acf" referenced memory at "0x0e6bfb70". The memory could not be "read". --- dump --- Unable to restore mru list - cannot instantiate input element: org.eclipse.jdt.u i.ClassFileEditorInputFactory Unable to restore mru list - cannot instantiate input element: org.eclipse.jdt.u i.ClassFileEditorInputFactory java.lang.ClassCastException at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.addSupe rTypeReference(AbstractIndexer.java(Compiled Code)) at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.addSupe rTypeReference(AbstractIndexer.java(Compiled Code)) at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.addSupe rTypeReference(AbstractIndexer.java(Compiled Code)) at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.addSupe rTypeReference(AbstractIndexer.java(Compiled Code)) at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.addClas sDeclaration(AbstractIndexer.java:26) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.indexClas sFile(BinaryIndexer.java(Compiled Code)) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.indexFile (BinaryIndexer.java:513) at org.eclipse.jdt.internal.core.search.indexing.AbstractIndexer.index(A bstractIndexer.java:558) at org.eclipse.jdt.internal.core.index.impl.Index.add(Index.java:88) at org.eclipse.jdt.internal.core.search.indexing.AddJarFileToIndex.execu te(AddJarFileToIndex.java:161) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:298) at java.lang.Thread.run(Thread.java:512) Writing Java core file .... Written Java core to C:\eclipse0416\eclipse\javacore.20020417.174216.1248.txt
Created attachment 657 [details] javacore.20020417.174216.1248.txt product of running test with -classic arg on Win2k
In order to disable the jit run with "-Djava.compiler=false" argument.
Thanks for the tip on -Djava.compiler=false. When I start Eclipse with "-Djava.compiler=false" the workbench comes up after 9 minutes. The second time I start Eclipse it takes ~30 seconds. I assume the JDT core was reindexing (which is slow in interpreted mode). I think the 04/16/02 18:07 java core file has a pointer to where the JIT code fails in JDT Core code. Maybe we could workaround this while IBM fixes the JIT compiler.
We are precisely working on improving the scenario when we silently handled such exception in SourceFile#getContents (used to ignore the issue and answer empty contents instead) to now stop the ongoing build process. This could indeed change the JIT behavior, unclear...
Closing as a JIT bug.
Do you want me to run this test with the new IBM JRE 1.3.1?
