Infinite loop in rename refactor makes Eclipse 2022.3 unusable

[dashorst]

While saving a file and letting Eclipse (2022.3) do its thing (saving, clean up, compiling) the editor of the file went blank and the GC started running awry. I was able to attach a Visual VM to the process and take two stack traces with about 1 minute time difference between one another.

I have no idea what code triggered this infinite loop, but I hope the stack traces will provide some clarity to the maintainers.

Update: Apparently I was renaming a method in a class. Also noteworthy: I had "Build automatically" turned off.

threaddump-1649936938159.tdump.txt

threaddump-1649937007990.tdump.txt

Apparently I was renaming something (a class name?) (using CTRL-1) when this infinite loop was triggered.

    at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:147)
    at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:51)
    at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:226)
    at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:165)
    at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:84)
    at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:41)
    at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:740)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2315)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2340)
    at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5923)
    at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:108)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)

[stephan-herrmann]

Looking at the first thread dump, the following block repeats more than what would look healthy:

    at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.cachedResolvedCopy(LambdaExpression.java:992)
    at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.resolveExpressionExpecting(LambdaExpression.java:1023)
    at org.eclipse.jdt.internal.compiler.lookup.ConstraintExpressionFormula.inputVariables(ConstraintExpressionFormula.java:513)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.lambda$1(InferenceContext18.java:601)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18$$Lambda$1319/0x00000008012c1fd0.perform(Unknown Source)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.collectingInnerBounds(InferenceContext18.java:535)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.addJDK_8153748ConstraintsFromFunctionalExpr(InferenceContext18.java:601)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.addJDK_8153748ConstraintsFromExpression(InferenceContext18.java:571)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.addJDK_8153748ConstraintsFromInvocation(InferenceContext18.java:556)
    at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.inferInvocationType(InferenceContext18.java:421)
    at org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.computeCompatibleMethod18(ParameterizedGenericMethodBinding.java:271)
    at org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.computeCompatibleMethod(ParameterizedGenericMethodBinding.java:92)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:841)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:798)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod0(Scope.java:1753)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1654)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:3044)
    at org.eclipse.jdt.internal.compiler.ast.MessageSend.findMethodBinding(MessageSend.java:1020)
    at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:835)
    at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:337)
    at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.resolveType(LambdaExpression.java:456)

I could not find recent changes in refactoring that could have led to this.

Thus we likely have a "normal" compiler bug. We can see that a lambda was involved which calls a generic method and perhaps more levels of nesting to thoroughly challenge type inference. It's strange if this bug doesn't surface during regular compilation, perhaps it does?

Unfortunately, that's about where analysis based only on the stack trace stops.

ERGO: a reproducing example would seem necessary for analysis.

[stephan-herrmann]

There's some similarity to https://bugs.eclipse.org/540763

[jukzi]

@dashorst please provide a reproducer

[jukzi]

There is not enough information provided to work on this issue. Please reopen if you can give reproducing steps.