Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: 1. Sometimes occurs on the first code completion after Eclipse startup, sometimes after few hours of work. First occured yesterday without any apparent reason More information: I have workspace 12 projects, most of them are relatevely small and only 5 of them are open (all small, up to 25 classes). 2 of them are dynamic Web projects, others plain Java projects. Starting from yesterday evening without any apparent reason (no Eclipse updates, no big changes in projects, no environment chages) Eclipse started to expirience StackOverflow quite regularly, sometimes directly after startup (on first Ctrl-Space in Java editor). Cleaning of projects seems to help for a while. Today I have installed latest available updates - no change in behavior.
Please attach the full .log. How much memory do you give Eclipse? >2 of them are dynamic Web projects How do you work with them? I assume you installed some additional plug-ins on top of Eclipse SDK. What? Callisto? WTP? Something else?
Hello, Memory -xmx512m, Plugins - yes it is Callisto distribution (WTP,DTP, BIRT) and SpringIDE. Regards, Oleksandr Alesinskyy
How do you specify the memory? Is it in the pure Java Editor or some other Editor where you see the problem (e.g. JSP editor? Can you reproduce with just Eclipse SDK?
Please leave on REMIND until all information is provided. We can't do anything until then.
Memory is specified in eclipse.ini, the whole ini follows: -vmargs -XX:MaxPermSize=160m -Xms40m -Xmx512m Command-line specifies only path to JVM (jrockit-R26.4.0-jdk1.5.0_06). I can not use Sun JDK due to PermGen problem (Bug 92250). Yes, it is pure Java editor, projects contain only pure Java and a litle bit of XML (web.xml and Spring context files), no JSP etc. And only Java editors are open (in Java perspective). I have not seen this problem with Eclipse SDK only. Some more remarks - proplems occurs (as far as I can see) only on name completion (e.g. if I have "someVariable" and type "someV" and then Ctrl-Space), method proposal etc. do not cause problem. Moreover, if problem occurs it persists after Eclipse restart (or event computer reboot) if I try to continue from the same name completion. If I comment this line, perform some other editing (semms it does not matter which), then remove comments and try the same name completion it works successfully.
>I have not seen this problem with Eclipse SDK only. OK, try this: take a look at the advanced code assist page and compare it with your install. Is there some additinal proposal kind available and/or enabled compared to plain Eclipse SDK? Can you try to get hold on the stack trace?
No, there is no difference if available/enabled proposals and they are in the same order, timeout is the same (50). Concerning the stack trace - it appears not each time (I run Eclipse not with javaw, but with java, so I see console window). One time I have catched stack trace, but forgot to save it from clipboard :( On other occurencies no stack trace has appeared in console window (only message box similar to "StackOverflow, do you like to exit workbench? ....." and after Ok Elipse closes without stck trace.
What's in Isn't the exception in the .log file?
Thak you, have not known about this file. ---------------------------------------------------- !ENTRY org.eclipse.ui 4 0 2006-12-13 00:31:31.231 !MESSAGE java.lang.StackOverflowError !STACK 0 java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:380) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:387) ----------------------------------
.
Moving to JDT Core. Looks like the problem is located there.
I cannot reproduce the bug or found where is the problem with the stack trace of comment 10. Could you attach to this bug report the .log file ? Could you give a test case or the source file which cause the exception ?
Created attachment 55581 [details] .log for StackOverflow
Created attachment 55582 [details] Offending Java file
So I have attache .log and java-file on which this error has occured most often, but I'm not sure if this file will be of great use as problem is unstable - comes and gone and even minor tweaking of source resolves it (for some time). And I completely understand that such unstable problems are the worst ones to fix. Regards, Oleksandr
Also see bug 167811
I am unable to reproduce the problem. Where do you perform code assist in the given file when the problem occur ? Do you reproduce the bug with another VM ? (sun or ibm)
In different places, normally, inside of one of action listeners. Problem is unstable as I have mentioned. I have switched to IBM JVM already and would see if there will be new cases. Sun JVM I can not use due to Bug 92250.
It as well occurs with IBM JVM. Offending file is attachedalong with .log
Created attachment 55731 [details] Offending Java file Errors occurs as well on IBM JVM, ofendingJava file along with .log are attached. Ctrl-Space at line 220 col 20 causes StackOverflow.
Created attachment 55732 [details] .log
Oops - mistyping, shall be line 270, column 20
Would it be possible to attach the whole project or provide a test case that we can use? The attached file won't help because too much is missing.
Hello, it seems that test case is almost impossible to produce - after I have completed that variable name myself I am able to continue with this project normally and code completion works in other places in the same file, even in the same method (till it will die next time). The whole project I just has no right to send - I will be immediately fired. Regards, Oleksandr
I can reproduce a stackoverflow with your file. Here is a smaller test case: package p; public class X { public void start(String terminal) { this.foo(new Object(){ public void bar() { if (zzz>(Integer)vvv.foo(i)) { return; } if (true) { return; } fch } }); } }
The stack overflow occurs in 3.2 but not in 3.3.
Hello, my congratulations! But your test case differs in one significant aspect - it has a lot of bugs (undefined variables), while in my situation before typing an "fch" file was error-free (may be some warnings, but I doubt it). Do not know, if it matter. Just have read your comment about 3.3. As far as I understand 3.3 is still under development? BTW, these StackOverflow crashes have one nasty side-effect - if at the moment of StackOverflow project was running on Tomcat inside Eclipse, then almost each time WTP plugin works incorrectly (after Eclipse restart), namely, publishing to server is affected, project becomes published to WebApplication directory in workspace (.metadata\.plugins\...) only partially (class files are copied properly, libraries sometimes yes and sometimes no and web.xml is not copied. XML and properties files that live in root of source directory are copied selectively (differently each time). As result manuyl repair is required. Is it worth it in your opinion to open separate bug report for WTP? Regards, Oleksandr
This is a problem of syntax error recovery specific to completion. So unresolved variable doesn't interact with the bug. 3.3 is still under development and the problem is fixed by the fix for bug 164311. The problem in 3.2 is another symptom of the problem fixed by the fix for bug 164311.
Given similar issue as bug 164311 addressed in 3.3 stream, +1 to backport the fix for 3.2.2.
Sorry, I do not understand what means "+1 to backport the fix for 3.2.2."
That means that we want to add the fix in 3.2 maintenance stream even if it's already fixed in the current development stream which is 3.3.
Thank you very much for explanation, I'm eagirely looking forward for this fix. Regards, Oleksandr
Created attachment 55756 [details] Proposed fix for 3.2.2
Fix released for 3.2.2. Test added CompletionTest#testBug164311_2() Oleksandr - When the next 3.2 Maintenance build will available, could you verify that your problem is gone ?
Added test CompletionTest#testBug164311_2() in 3.3.
Gladly.
Verified for 3.2.2 using build M20060112-1200.
