Community
Participate
Working Groups
Created attachment 205936 [details] Workspace log I20111018-0850 I had something like this... List<SomeTypeName> x = new ArrayList<STN>(); ...and I tried to invoke code completion between the 'N' and the '>' in the array list instantiation part. After a bit of processing, Eclipse told me that it had gotten a stack overflow. java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:446) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453)
I couldn't reproduce on an independent test case. Is it possible to share the exact compilation unit where it happened?
Created attachment 205949 [details] Workspace with a test project (zip file) Please try to reproduce with I20111018-0850 or above.
I use p2 to update to I20111018-0850. When it was first unzipped the build was I20110927-0800. I cannot reproduce the problem with a newly unzipped I20111025-1043 (4.x).
i can confirm this also happens on indigo 3.7 sr 2 eclipse.buildId=M20110909-1335 java.version=1.6.0_27 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=iw_IL Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product Error Tue Dec 06 21:36:28 IST 2011 Unhandled event loop exception java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToParameterizedType(LookupEnvironment.java:453)
(In reply to comment #4) > i can confirm this also happens on indigo 3.7 sr 2 > > eclipse.buildId=M20110909-1335 Note that SR2 has not been released yet. You are using SR1.
Created attachment 208135 [details] A simple code snippet that can easily be used to reproduce the error Hopefully this is helpful... I ran into this problem today when I was trying to do completion on some code that really shouldn't be possible to complete. I've attached a code snippet that does it. If you trigger completion after the comma in the construction of the new HashMap the stack overflow occurs.
(In reply to comment #6) > Created attachment 208135 [details] > A simple code snippet that can easily be used to reproduce the error Thanks a lot Leo. I can reproduce consistently with this snippet. Happens due to recursive call of LookupEnvironment#convertToParameterizedType(..) This is a regression in 3.7 over 3.6.2. Possible candidate for 3.7.2
(In reply to comment #7) > This is a regression in 3.7 over 3.6.2. Possible candidate for 3.7.2 Agreed, but will reset target to 3.8 M5 so this stays in the radar for M5 planning. After fix becomes available, we can evaluate back port options.
I've seen the problem too. eclipse.buildId=M20110909-1335 java.version=1.6.0_26 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_NZ Framework arguments: -showlocation -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -showlocation -product org.eclipse.epp.package.jee.product
(In reply to comment #9) > I've seen the problem too. Let us know if you have a test case that you can put here. Although we already have test cases submitted above, the more the better. :)
(In reply to comment #6) > Created attachment 208135 [details] > A simple code snippet that can easily be used to reproduce the error > > Hopefully this is helpful... Thanks, Even shorter example: public class X { void g() { return new X() { void g() { Object o = new HashMap<|
(In reply to comment #11) [...] > return new X() { > void g() { > Object o = new HashMap<| We are confusing the inner allocation expression to be a qualified allocation expression of the form new X().new HashMap Patch will follow shortly.
Created attachment 209358 [details] Patch under test This patches fixes the problem and also passes RunAllCompletionTests. Running all tests now.
Released via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=b51c36b1246bd1345c3afae01728763dcd171e5a for 3.8 M5.
(In reply to comment #13) > Created attachment 209358 [details] > Patch under test The patch looks good. Since this is a regression, should we consider for 3.7.2?
(In reply to comment #15) > The patch looks good. Since this is a regression, should we consider for 3.7.2? (In reply to comment #7) > This is a regression in 3.7 over 3.6.2. Possible candidate for 3.7.2 Dani, four different individuals have run into this bug and have commented on this entry. It is a single line fix and I would say a safe fix. Patch has been reviewed by Ayush. We would like this for 3.7.2.
(In reply to comment #16) > (In reply to comment #15) > > > The patch looks good. Since this is a regression, should we consider for 3.7.2? > > (In reply to comment #7) > > > This is a regression in 3.7 over 3.6.2. Possible candidate for 3.7.2 > > Dani, four different individuals have run into this bug and have > commented on this entry. It is a single line fix and I would say > a safe fix. Patch has been reviewed by Ayush. We would like this > for 3.7.2. +1 for 3.7.2.
Reopening for backport.
Released into 3.7 maintenance via commit 41e56888a23cc57b7575089de55ab6cc49d9a85d
Verified for 3.7.2RC2 using build M20120118-0800
This seem to have been missed out in our M5 verification. Marking it for M6.
Verified for 3.8 M6 using build I20120312-1800
*** Bug 378007 has been marked as a duplicate of this bug. ***
