Bugzilla – Full Text Bug Listing
| Summary: | UI Freeze when refactoring using new Java index | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Philippe Cadé <philippe.cade> | ||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Manoj N Palat <manoj.palat> | ||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | jarthana, loskutov, stephan.herrmann | ||||
| Version: | 4.7.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows NT | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Stays the UI frozen forever, or it just freezes while indexing? Related part shows that the new Indexer waiting for indexing to complete directly in the UI thread: Thread 0: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - org.eclipse.core.internal.jobs.Semaphore.acquire(long) @bci=54, line=39 (Compiled frame) - org.eclipse.core.internal.jobs.JobManager.join(org.eclipse.core.internal.jobs.InternalJob, long, org.eclipse.core.runtime.IProgressMonitor) @bci=314, line=908 (Interpreted frame) - org.eclipse.core.internal.jobs.InternalJob.join(long, org.eclipse.core.runtime.IProgressMonitor) @bci=6, line=345 (Interpreted frame) - org.eclipse.core.runtime.jobs.Job.join(long, org.eclipse.core.runtime.IProgressMonitor) @bci=3, line=582 (Interpreted frame) - org.eclipse.jdt.internal.core.nd.indexer.Indexer.waitForIndex(org.eclipse.core.runtime.IProgressMonitor) @bci=50, line=1021 (Interpreted frame) - org.eclipse.jdt.internal.core.nd.indexer.Indexer.waitForIndex(int, org.eclipse.core.runtime.IProgressMonitor) @bci=59, line=1042 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.newSearchAllPossibleSubTypes(org.eclipse.jdt.core.IType, org.eclipse.jdt.core.search.IJavaSearchScope, java.util.Map, org.eclipse.jdt.internal.core.IPathRequestor, int, org.eclipse.core.runtime.IProgressMonitor) @bci=24, line=498 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.searchAllPossibleSubTypes(org.eclipse.jdt.core.IType, org.eclipse.jdt.core.search.IJavaSearchScope, java.util.Map, org.eclipse.jdt.internal.core.IPathRequestor, int, org.eclipse.core.runtime.IProgressMonitor) @bci=26, line=483 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.determinePossibleSubTypes(java.util.HashSet, org.eclipse.core.runtime.IProgressMonitor) @bci=25, line=440 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(boolean) @bci=92, line=152 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute() @bci=25, line=319 (Interpreted frame) - org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(org.eclipse.core.runtime.IProgressMonitor) @bci=164, line=1291 (Interpreted frame) - org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation() @bci=5, line=90 (Interpreted frame) - org.eclipse.jdt.internal.core.JavaModelOperation.run(org.eclipse.core.runtime.IProgressMonitor) @bci=53, line=724 (Compiled frame) - org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(org.eclipse.core.runtime.IProgressMonitor) @bci=32, line=790 (Compiled frame) - org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(org.eclipse.jdt.core.WorkingCopyOwner, org.eclipse.core.runtime.IProgressMonitor) @bci=27, line=831 (Interpreted frame) - org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(org.eclipse.core.runtime.IProgressMonitor) @bci=5, line=789 (Interpreted frame) - org.eclipse.jdt.internal.corext.refactoring.structure.ChangeSignatureProcessor.getCachedTypeHierarchy(org.eclipse.core.runtime.IProgressMonitor) @bci=26, line=720 (Interpreted frame) - org.eclipse.jdt.internal.corext.refactoring.structure.ChangeSignatureProcessor.checkInitialConditions(org.eclipse.core.runtime.IProgressMonitor) @bci=166, line=739 (Interpreted frame) - org.eclipse.jdt.internal.corext.refactoring.RefactoringExecutionStarter.startChangeSignatureRefactoring(org.eclipse.jdt.core.IMethod, org.eclipse.jdt.ui.actions.SelectionDispatchAction, org.eclipse.swt.widgets.Shell) @bci=25, line=184 (Interpreted frame) - org.eclipse.jdt.ui.actions.ModifyParametersAction.run(org.eclipse.jface.text.ITextSelection) @bci=30, line=148 (Interpreted frame) - org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(org.eclipse.jface.viewers.ISelection) @bci=48, line=275 (Interpreted frame) - org.eclipse.jdt.ui.actions.SelectionDispatchAction.run() @bci=5, line=249 (Interpreted frame) - org.eclipse.jface.action.Action.runWithEvent(org.eclipse.swt.widgets.Event) @bci=1, line=473 (Interpreted frame) - org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(org.eclipse.swt.widgets.Event, boolean) @bci=352, line=565 (Interpreted frame) - org.eclipse.jface.action.ActionContributionItem.lambda$4(org.eclipse.swt.widgets.Event) @bci=54, line=397 (Compiled frame) - org.eclipse.jface.action.ActionContributionItem$$Lambda$226.handleEvent(org.eclipse.swt.widgets.Event) @bci=5 (Compiled frame) - org.eclipse.swt.widgets.EventTable.sendEvent(org.eclipse.swt.widgets.Event) @bci=214, line=86 (Compiled frame) But the problem is most likely not related to the new index: the code calling the indexer *explicitly* requests to wait for the index to be ready, see org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.determinePossibleSubTypes(HashSet, IProgressMonitor) searchAllPossibleSubTypes( getType(), this.scope, this.binariesFromIndexMatches, collector, IJavaSearchConstants.WAIT_UNTIL_READY_TO_SEARCH, monitor); And this code is not used by the new indexer only. I haven't waited that Eclipse would come out of the freeze, I killed it after several minutes. Also it does not always happen: I was able to reproduce several times but now after rebuilding the index, using the new or old index, I am able to perform the refactoring on the same piece of code without a delay. Note: our code base is rather large, Eclipse reports more than 7 million lines of code; Sonar says we have 5 million. Next time I have such a situation, what kind of additional information shall I provide to help and track the problem? (In reply to Philippe Cadé from comment #2) > Next time I have such a situation, what kind of additional information shall > I provide to help and track the problem? It would be interesting to see if the UI recovers after the freeze: this would help to understand do we have a deadlock or just a very long indexing time. Reading through the stack dump I could not identify any candidate for a true deadlock, no indication of any contention regarding the Semaphore etc. What we do see is some activity from jdt.debug, including two instances of ProcessConsole waiting for data. => Does the problem also occur with no current debugging activity? It's a bit hard to reproduce so I can't tell if the debugger needs to be halted on a breakpoint for this to happen. However I noticed that I can reproduce this if I trigger a refactoring just after forcing an index rebuild. I forced an index rebuild going from the new index to the old one. I could see the number of files to index while Eclipse was blocked with a turning wheel. The refactoring was successful once the index rebuild was finished. So in the end, it is not a freeze but just a long wait. (In reply to Philippe Cadé from comment #5) Thanks for the update ... > However I noticed that I can reproduce this if I trigger a refactoring just > after forcing an index rebuild. I forced an index rebuild going from the new > index to the old one. so that would be a problem in the old index, right? do you see a difference between new->old and old->new switching? It is the same behavior if I rebuild the index going from the old to the new, the refactoring is waiting that the index is rebuild. So I am not sure if this is really a bug then. If the refactoring relies on index data to perform its job, it makes sense that it waits. May be the UI should be improved instead: I would rather like to see a "User Operation is Waiting" dialog with a progress on the index rebuilding and the option to cancel my refactoring instead of seeing a spinning wheel for minutes and not knowing what is happening in the background. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Created attachment 270830 [details] Thread dump during freeze after starting a refactoring The UI freezes when starting a refactoring, for example renaming a method or renaming a method parameter. This only happens when the new Java index is enabled. When the new Java index is enabled, the refactoring is successful.