Community
Participate
Working Groups
First, many thanks for the great software you created. This is the first time I wrote a email to eclipse community and I am not quite clear that in what format I should write this mail. I apologize for the inconvenience. Well, the following is the description of the problem I met. I ran eclipse3 RC2 on the SUN JDK 1.4.2_04. Then I created 3 project with one as the main project and the other two for reference. Both 3 project use linked resource for the source folder and I added some libraries to their build classpath using User Libraries. When build the projects, the 2 reference projects got built without errors but the main project got an error saying "Build Workspace (Error: an internal error occurred during: "Build Workspace".)" and the build process stopped without all source files compiled. The detail stacktrace contained not much information which says only "java.lang.StackOverflowError". Below is the log: ****************** begin ****************** !SESSION 6 18, 2004 14:11:09.321 ----------------------------------------------- eclipse.buildId=I200406111814 java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ja_JP !ENTRY org.eclipse.core.runtime 4 2 6 18, 2004 14:11:09.321 !MESSAGE An internal error occurred during: "Building Workspace". !STACK 0 java.lang.StackOverflowError ****************** end ****************** And then I tried to ran eclipse3 RC2 on SUN JDK 1.5.0 beta2. This time I got a different log which contain lots of detail messages. And it also seemed that there were not only the problem I describe above, but also some problem when eclipse tries to save the main project with the message "Could not write metadata for: /KelpJB_addinJBX.". The log of the try on JDK1.5 is as follows: ****************** end ****************** !SESSION 6 18, 2004 14:12:06.447 ----------------------------------------------- eclipse.buildId=I200406111814 java.version=1.5.0-beta2 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ja_JP !ENTRY org.eclipse.core.runtime 4 2 6 18, 2004 14:12:06.447 !MESSAGE An internal error occurred during: "Building Workspace". !STACK 0 java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:147) at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:149) at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:155) ************ I omitted 1018 lines here because they are just the repetition of the above 2 lines *********** at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:149) at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:155) at org.eclipse.jdt.internal.compiler.lookup.Scope.faultInReceiverType (Scope.java:149) !ENTRY org.eclipse.ui.ide 4 4 6 18, 2004 14:12:15.822 !MESSAGE Problems saving workspace !ENTRY org.eclipse.ui.ide 4 1 6 18, 2004 14:12:15.822 !MESSAGE Problems occurred while trying to save the state of the workbench. !SUBENTRY 1 org.eclipse.core.resources 4 568 6 18, 2004 14:12:15.822 !MESSAGE Could not write metadata for: /KelpJB_addinJBX. !STACK 0 java.io.UTFDataFormatException: encoded string too long: 90168 bytes at java.io.DataOutputStream.writeUTF(DataOutputStream.java:345) at java.io.DataOutputStream.writeUTF(DataOutputStream.java:305) at org.eclipse.core.internal.resources.MarkerWriter.write (MarkerWriter.java:181) at org.eclipse.core.internal.resources.MarkerWriter.write (MarkerWriter.java:210) at org.eclipse.core.internal.resources.MarkerWriter.save (MarkerWriter.java:107) at org.eclipse.core.internal.resources.MarkerManager.save (MarkerManager.java:482) at org.eclipse.core.internal.resources.SaveManager$3.visitElement (SaveManager.java:1467) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:78) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration (ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate (ElementTreeIterator.java:123) at org.eclipse.core.internal.resources.SaveManager.visitAndSave (SaveManager.java:1491) at org.eclipse.core.internal.resources.SaveManager.visitAndSave (SaveManager.java:1527) at org.eclipse.core.internal.resources.SaveManager.save (SaveManager.java:1335) at org.eclipse.core.internal.resources.Workspace.save (Workspace.java:1707) at org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor$5.run (IDEWorkbenchAdvisor.java:468) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:101) ****************** end ****************** This is the problem I met and I hope you can fix it (if it really is a bug). Thank you. A eclipse fan Zhang.
Could you attach a testcase reproducing this issue ? I am suspecting a very long sequence of message send or something like that. You may increase the amount of memory allocated for execution stack using VM args on command line "-Xss256K" (eclipse.exe -vmargs -Xss256k). But still we should understand what caused this to occur.
Dear Philippe Mulet, Thank you for your quick reply. I tried just as you wrote but there was no lucky and the problem remains. Here is my command line to invoke eclipse: D:\eclipse\eclipse3RC2\eclipse.exe -vm d:\java\j2sdk142\bin\javaw.exe -data d:\eclipse\eclipse3-workspace -vmargs -Xmx160m -Xss512k Now I'm trying to make a testcase you mentioned but have not much confidence. I'll try my best. Zhang
Please do not modify target on bugs, this is dvpt team responsibility to do that... Thanks
Can you reproduce this issue on a 1.4 JDK ? Note that 1.5 JDKs are fairly unstable (these are just betas).
Created attachment 12469 [details] Testcase project for reproducing the error
Dear JDT Core team members, I think I got the procedure to reproduce the error on JDK 1.4.2. Please unzip the attached zip archive which contains the testcase project. Here is the procedure: (1) Use the following command line to start eclipse 3 RC2.(it's just what I used) D:\eclipse\eclipse3RC2\eclipse.exe -vm d:\java\j2sdk142\bin\javaw.exe -data g:\workspace -vmargs -Xmx160m -Xss512k (2) Open a clean(newly created) workspace. (3) Import the project from disk using "Import | existing project into workspace". (4) Update the external jar entry "jbuilder.jar" in the project build path. Please use the "jbuilder.jar" in JBuilder7 (it is in the bin folder under the product installation folder). A JBuilder7 trial version contains this file I believe. (of course the retail version also) Sorry for the inconvinience but I cannot provide the jar file. It's too big and I do not know if it's legal to provide it. (5) Build the project and a dialog reporting the error will pop up. Note: I noticed that not only building the project, but saving the TestCase.java file or refreshing the project will also produce the similar error. So this may be the JDT UI problem. I'm not sure but if it's really a UI problem, would you please report this problem to the JDT UI team? yours truly, Zhang
Proposed fix, replace the following line in faultInReceiverType: if (type instanceof BinaryTypeBinding && (type.tagBits & EndHierarchyCheck) == 0) { with: if (type instanceof BinaryTypeBinding && (type.tagBits & BeginHierarchyCheck) == 0) { type.tagBits |= BeginHierarchyCheck;
Code change looks good. I cannot reproduce it from reporter's testcase, as cannot gain access to jbuilder.jar. Hao - would it be possible to remove dependencies from jbuilder on your test case, and produce a standalone testcase ? It looks like an infinite recursion is occurring in our compiler. Note that this would also induce the problem in UI or anywhere our compiler is invoked.
Forgot to mention this is a regression introduced with fix for bug 61706
It feels to me that the only situation where such a regression could occur is a case where binaries would end up forming a cycle either in type hierarchy or enclosing type link. But both are forbidden in theory.
In presence of cycles in binaries (assuming this would be the case here), I don't think this behavior would have been a regression based on 2.1, since the stack overflow would then have occurred during reference recording as opposed to during faulting in of receiver type.
Created attachment 12562 [details] Scope patch
Created attachment 12563 [details] JDT core tests patch
Test case is a manually created cycle in binary superclass chain.
Actually, re: comment#11. The reference recording code in 2.1 was protected by a guard ensuring only new types were considered. This was thus handling possible looping scenarii in a satisfactory manner. With our eager resolution, we are now subject to stack overflow if such binaries come across in a way where they would not be involved in any supertype hierarchy (first occurrence is as a receiver type of some message send/field access). Will send reporter a patch to assess the fix. The fix itself is quite trivial, and given we are resilient everywhere else for corrupted binaries (in particular cycling ones when resolving type hierarchies), we should consider it for 3.0 (as it is a regression from previous releases). There is no workaround to avoid this issue, except than rebuilding offending libraries. However, given some products seem to ship with such libraries, we should behave.
I'm quite excited to report that the issue I encountered disappeared after I applied the patch (jdtcore.jar) philippe mulet (philippe_mulet@fr.ibm.com) sent to me. The project just builds as is in eclipse 2.1.3. I don't know what detail information you interest in, so I don't know what I should tell you. Please tell me if any detail description is needed.
Thanks for confirming this.
Approved to be released into RC4
Fix released for integration, with NegativeTest#test431
Fixed for RC4.
Released fix is correct.
