Community
Participate
Working Groups
Build 20020205 using Team 2.0 - Went to open type - got progress dialog indicating "110 files to index" - it hung there - hit cancel - got Type Selection / No types available dialog - tried again - got the same thing - tried closing the projects I had been working on - this had no effect - I had recently done a synchronize where I released one file (in org.eclipse.ui.tests) - exited and restarted - tried again - it indexed over 1000 files, taking 30 secs or so on a fast machine - the open type dialog came up properly though
moving to JDT Core for investigation
Got a similar one, indexer died in the background due to a crash in the index layer (or JIT?. While waiting a ctrl-pause shows that the indexing thread was gone. Full thread dump: "ModalContext" prio=5 tid=0x12096d90 nid=0x534 waiting on monitor [0x15caf000..0x15cafdbc] at java.lang.Thread.sleep(Native Method) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob (JobManager.java:216) at org.eclipse.jdt.core.search.SearchEngine.search (SearchEngine.java:395) at org.eclipse.jdt.core.search.SearchEngine.search (SearchEngine.java:353) at org.eclipse.jdt.internal.ui.search.JavaSearchOperation.execute (JavaSearchOperation.java:82) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run (WorkspaceModifyOperation.java:64) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1343) at org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:78) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:98) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=2 tid=0x1135fe88 nid=0x644 waiting on monitor [0x15c6f000..0x15c6fdbc] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:128) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=2 tid=0x113629e8 nid=0x4e8 waiting on monitor [0x15a5f000..0x15a5fdbc] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:128) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=2 tid=0x13b5ed00 nid=0x1e4 waiting on monitor [0x157af000..0x157afdbc] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:128) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=2 tid=0x12017740 nid=0x500 runnable [0x1576f000..0x1576fdbc] at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:128) "Evaluation thread" prio=5 tid=0x13b4e940 nid=0x648 waiting on monitor [0x1498f000..0x1498fdbc] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine$1.run (ASTEvaluationEngine.java:178) at java.lang.Thread.run(Thread.java:484) "Signal Dispatcher" daemon prio=10 tid=0x803538 nid=0x408 waiting on monitor [0..0] "Finalizer" daemon prio=9 tid=0x819d18 nid=0x4fc waiting on monitor [0x114ef000..0x114efdbc] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162) "Reference Handler" daemon prio=10 tid=0x11230290 nid=0x558 waiting on monitor [0x114af000..0x114afdbc] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110) "main" prio=5 tid=0x2345f8 nid=0x124 runnable [0x6f000..0x6fc34] at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) at org.eclipse.swt.widgets.Display.sleep(Display.java:1621) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block (ModalContext.java:134) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:258) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run (ProgressMonitorDialog.java:335) at org.eclipse.jdt.internal.ui.search.ElementSearchAction.run (ElementSearchAction.java:77) at org.eclipse.jdt.internal.ui.search.JavaElementAction.run (JavaElementAction.java:86) at org.eclipse.jdt.internal.ui.search.WorkingSetAction.run (WorkingSetAction.java:21) at org.eclipse.jface.action.Action.runWithEvent(Action.java:590) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:361) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:352) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:47) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:75) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:637) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1412) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1208) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:836) at org.eclipse.ui.internal.Workbench.run(Workbench.java:819) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:777) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:319) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:190) at org.eclipse.core.launcher.Main.run(Main.java:549) at org.eclipse.core.launcher.UIMain.main(UIMain.java:52) "VM Thread" prio=5 tid=0x805260 nid=0x580 runnable "VM Periodic Task Thread" prio=10 tid=0x819190 nid=0x3d4 waiting on monitor "Suspend Checker Thread" prio=10 tid=0x8183c0 nid=0x128 runnable
We have identified a possible collision in index writing, when needing to save changes, the write lock is exited, and the read lock is taken. If in between someone does acquire the write lock again (background indexer), then the read job will trigger a save (merge) action which could be fatal if multiple threads are doing the same. The odd it occurs is fairly very low, but it is feasible. Fixed, also added some crash recovery on the indexer (will restart) in case some badness occurs. Thus this problem should be fixed.
*** Bug 13234 has been marked as a duplicate of this bug. ***
