Community
Participate
Working Groups
Build ID: I20080516-1333 Steps To Reproduce: 1.input this line: private Map<Class<?>,List<Field>> map = new Hashmap 2.where Map List already imported import java.util.List; import java.util.Map; 3.now Alt+/ jdt report outofMemory More information: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuilder.append(StringBuilder.java:119) at java.lang.StackTraceElement.toString(StackTraceElement.java:157) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at java.lang.Throwable.printStackTrace(Throwable.java:464) at java.lang.Throwable.printStackTrace(Throwable.java:451) at org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:593) at org.eclipse.jdt.core.dom.CompilationUnitResolver.handleInternalException(CompilationUnitResolver.java:317) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:767) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.internal.ui.text.java.LazyGenericTypeProposal.getExpectedType(LazyGenericTypeProposal.java:603) at org.eclipse.jdt.internal.ui.text.java.LazyGenericTypeProposal.computeTypeArgumentProposals(LazyGenericTypeProposal.java:298) at org.eclipse.jdt.internal.ui.text.java.LazyGenericTypeProposal.apply(LazyGenericTypeProposal.java:195) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:443) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:923) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$21(CompletionProposalPopup.java:887) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:492) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:479) at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1662) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:177) at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185) at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:109) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
The problem is an infinite loop in the BindingKeyResolver for the following binding key: "Ljava/util/Map<Ljava/lang/Class<Ljava/lang/Class;*>;Ljava/util/List<LField;>;>;", With this case, the first loop in BindingKeyParser.parseParameterizedType(char[], boolean) never ends. This bug was introduced in 3.3 by the fix to bug 111529. The fact that an IllegalArgumentException is thrown and then caught fails to have the scanner progress for parameterized type. As a result, the isAtParametersEnd() condition is never true. This code was not used by code assist in 3.3, so this bug cannot be reproduced in 3.3. This makes it a regression from a user point of view comparing to 3.3. We should fix it for RC3.
Created attachment 101731 [details] Proposed fix and regression test
Given it no longer escapes with the proposed patch, does it exit properly from such a bogus scenario ? List<Zork>.Map<Object,Number> i.e. it should not ignore the (bogus) leading part.
(In reply to comment #3) > Given it no longer escapes with the proposed patch, does it exit properly from > such a bogus scenario ? > > List<Zork>.Map<Object,Number> > > i.e. it should not ignore the (bogus) leading part. > In this scenario, an NPE would be logged to the .log file and null would be returned.
Created attachment 101771 [details] New proposed fix and new regression tests This patch fixes the issue noticed by Philippe, and it adds more tests.
Philippe, Frederic and David, could you please review?
Patch looks good: +1
Created attachment 102124 [details] Same patch with more null checks
+1 for 3.4RC3 Minor comment (perf): this.types = new ArrayList(); --> this.types.clear(); Going into performance, as per discussion with Jerome, there may be other enhancements to make so as to avoid allocating multiple resolvers etc... but this is a separate issue.
Fix and tests released for 3.4RC3
Verified for 3.4RC4 using build I20080530-0100
