Community
Participate
Working Groups
I've been using 3.0 m3 the past several days, and one thing that has been hanging it up quite frequently is hitting control-s and then control-b in quick succession. I'd say in the past 4 days, its hung Eclipse up on me 20 times. Not positive this stack is directly associated with the error, but this is what I got in my .log: !ENTRY org.eclipse.core.runtime 4 2 Sep 02, 2003 17:07:50.625 !MESSAGE Problems occurred when invoking code from plug- in: "org.eclipse.core.runtime". !STACK 0 java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification (AbstractList.java:448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at org.eclipse.ui.internal.progress.StatusLineProgressListener.getNextMessage (StatusLineProgressListener.java:134) at org.eclipse.ui.internal.progress.StatusLineProgressListener.remove (StatusLineProgressListener.java:113) at org.eclipse.ui.internal.progress.JobProgressManager.remove (JobProgressManager.java:360) at org.eclipse.ui.internal.progress.JobProgressManager.done (JobProgressManager.java:300) at org.eclipse.core.internal.jobs.JobListeners$3.notify (JobListeners.java:37) at org.eclipse.core.internal.jobs.JobListeners$7.run (JobListeners.java:96) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:1016) at org.eclipse.core.runtime.Platform.run(Platform.java:420) at org.eclipse.core.internal.jobs.JobListeners.doNotify (JobListeners.java:86) at org.eclipse.core.internal.jobs.JobListeners.done (JobListeners.java:125) at org.eclipse.core.internal.jobs.JobManager.endJob (JobManager.java:292) at org.eclipse.core.internal.jobs.WorkerPool.endJob(WorkerPool.java:50) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:74)
Move to Platform/UI.
Fixed in build >20030804. The problem code was pretty clear (iterators are not Thread safe) but I was not able to reproduce the problem myself. I would appreciate it if you could double check this when you get a newer build.
*** Bug 42546 has been marked as a duplicate of this bug. ***
I am still having problems with when I rapidly hit control-s and then control- b to save and build causing eclipse to hang where I have to kill the process. I do have a dual xeon machine/hyperthreading so I have 4 logical CPU's, so I'm not sure if this is indicative of a deadlock issue or what.
Got it to happen, had console window open, so here's a thread dump: Full thread dump Java HotSpot(TM) Client VM (1.4.2_01-b06 mixed mode): "ModalContext" prio=7 tid=0x06c5a608 nid=0x188 in Object.wait() [750f000..750fd94] at java.lang.Object.wait(Native Method) - waiting on <0x10263108> (a org.eclipse.core.internal.jobs.ImplicitJobs$ThreadJob) at org.eclipse.core.internal.jobs.ImplicitJobs$ThreadJob.joinRun (ImplicitJobs.java:61) - locked <0x10263108> (a org.eclipse.core.internal.jobs.ImplicitJobs$ThreadJob) at org.eclipse.core.internal.jobs.ImplicitJobs.begin (ImplicitJobs.java:178) at org.eclipse.core.internal.jobs.JobManager.beginRule (JobManager.java:113) at org.eclipse.core.internal.resources.WorkManager.checkIn (WorkManager.java:79) at org.eclipse.core.internal.resources.Workspace.prepareOperation (Workspace.java:1551) at org.eclipse.core.internal.resources.Workspace.build (Workspace.java:179) at org.eclipse.ui.actions.GlobalBuildAction$1.run (GlobalBuildAction.java:174) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:101) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x00a446b0 nid=0x488 in Object.wait() [74cf000..74cfd94] at java.lang.Object.wait(Native Method) - waiting on <0x12c25b30> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:161) - locked <0x12c25b30> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) "Worker-3" prio=7 tid=0x0611f178 nid=0x180 waiting on condition [748f000..748fd94] at java.lang.Thread.sleep(Native Method) at org.eclipse.ui.internal.progress.AnimationManager.animateLoop (AnimationManager.java:317) at org.eclipse.ui.internal.progress.AnimationManager$3.run (AnimationManager.java:466) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:61) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x05c98d98 nid=0x79c waiting for monitor entry [69ef000..69efd] at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile (JavaReconcilingStrategy.java:72) - waiting to lock <0x11e3f618> (a org.eclipse.jdt.internal.core.CompilationUnit) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile (JavaReconcilingStrategy.java:99) at org.eclipse.jface.text.reconciler.MonoReconciler.process (MonoReconciler.java:76) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:189) "Worker-2" prio=7 tid=0x05d1d730 nid=0xa5c in Object.wait() [688f000..688fd94] at java.lang.Object.wait(Native Method) - waiting on <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:95) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:116) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Worker-1" prio=7 tid=0x0612a540 nid=0x61c in Object.wait() [677f000..677fd94] at java.lang.Object.wait(Native Method) - waiting on <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:95) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:116) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Worker-0" prio=7 tid=0x0612a710 nid=0x924 in Object.wait() [673f000..673fd94] at java.lang.Object.wait(Native Method) - waiting on <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:95) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob (WorkerPool.java:116) - locked <0x11077680> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x0606b138 nid=0xf0 runnable [66ef000..66efd94] at java.lang.Object.wait(Native Method) - waiting on <0x113fead0> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:161) - locked <0x113fead0> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) "Java indexing" daemon prio=4 tid=0x05f78608 nid=0xa48 in Object.wait() [66af000..66afd94] at java.lang.Object.wait(Native Method) - waiting on <0x111b8e20> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager) at java.lang.Object.wait(Object.java:429) at org.eclipse.jdt.internal.core.search.processing.JobManager.run (JobManager.java:358) - locked <0x111b8e20> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager) at java.lang.Thread.run(Thread.java:534) "Signal Dispatcher" daemon prio=10 tid=0x00a30e70 nid=0x82c waiting on condition [0..0] "Surrogate Locker Thread (CMS)" daemon prio=5 tid=0x00a2fa98 nid=0x244 waiting on condition [0..5b4ff34] "Finalizer" daemon prio=9 tid=0x00a2d6e8 nid=0x678 in Object.wait() [5b0f000..5b0fd94] at java.lang.Object.wait(Native Method) - waiting on <0x11014ca0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x11014ca0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x00a2c2b8 nid=0x87c in Object.wait() [5acf000..5acfd94] at java.lang.Object.wait(Native Method) - waiting on <0x11010010> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked <0x11010010> (a java.lang.ref.Reference$Lock) "main" prio=7 tid=0x00035c50 nid=0x334 runnable [7e000..7fc3c] at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) at org.eclipse.swt.widgets.Display.sleep(Display.java:2484) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block (ModalContext.java:137) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:261) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run (ProgressMonitorDialog.java:357) at org.eclipse.ui.actions.GlobalBuildAction.doBuildOperation (GlobalBuildAction.java:186) at org.eclipse.ui.actions.GlobalBuildAction.run (GlobalBuildAction.java:240) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.ui.internal.commands.ActionHandler.execute (ActionHandler.java:44) at org.eclipse.ui.internal.Workbench.press(Workbench.java:454) at org.eclipse.ui.internal.Workbench$2.handleEvent(Workbench.java:212) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:646) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:846) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:871) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:856) at org.eclipse.swt.widgets.Control.sendKeyEvent(Control.java:1688) at org.eclipse.swt.widgets.Control.sendKeyEvent(Control.java:1684) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3014) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2893) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2712) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1343) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1875) at org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.runEventLoop (EventLoopProgressMonitor.java:94) at org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.subTask (EventLoopProgressMonitor.java:124) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask (ProgressMonitorWrapper.java:120) at org.eclipse.core.runtime.SubProgressMonitor.subTask (SubProgressMonitor.java:161) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask (ProgressMonitorWrapper.java:120) at org.eclipse.core.runtime.SubProgressMonitor.subTask (SubProgressMonitor.java:161) at org.eclipse.core.runtime.SubProgressMonitor.done (SubProgressMonitor.java:130) at org.eclipse.core.internal.resources.AutoBuildJob.doBuild (AutoBuildJob.java:72) at org.eclipse.core.internal.resources.AutoBuildJob.run (AutoBuildJob.java:97) at org.eclipse.core.internal.resources.Workspace.endOperation (Workspace.java:869) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1593) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1603) at org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:85) - locked <0x12f4de60> (a org.eclipse.ui.texteditor.AbstractTextEditor$17) at org.eclipse.ui.texteditor.AbstractTextEditor.performSaveOperation (AbstractTextEditor.java:3190) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.performSaveOperati on(CompilationUnitEditor.java:821) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSave (CompilationUnitEditor.java:885) - locked <0x11e3f618> (a org.eclipse.jdt.internal.core.CompilationUnit) at org.eclipse.ui.internal.EditorManager$11.run (EditorManager.java:1090) at org.eclipse.ui.internal.EditorManager$8.run(EditorManager.java:960) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:302) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:252) at org.eclipse.jface.window.ApplicationWindow$1.run (ApplicationWindow.java:444) at org.eclipse.swt.custom.BusyIndicator.showWhile (BusyIndicator.java:84) at org.eclipse.jface.window.ApplicationWindow.run (ApplicationWindow.java:441) at org.eclipse.ui.internal.WorkbenchWindow.run (WorkbenchWindow.java:1596) at org.eclipse.ui.internal.EditorManager.runProgressMonitorOperation (EditorManager.java:966) at org.eclipse.ui.internal.EditorManager.savePart (EditorManager.java:1095) at org.eclipse.ui.internal.WorkbenchPage.savePart (WorkbenchPage.java:2381) at org.eclipse.ui.internal.WorkbenchPage.saveEditor (WorkbenchPage.java:2393) at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:57) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:529) at org.eclipse.jface.action.ActionContributionItem.access$4 (ActionContributionItem.java:482) at org.eclipse.jface.action.ActionContributionItem$6.handleEvent (ActionContributionItem.java:454) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:847) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2187) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1877) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2037) at org.eclipse.ui.internal.Workbench.run(Workbench.java:2020) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:858) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:295) at org.eclipse.core.launcher.Main.run(Main.java:751) at org.eclipse.core.launcher.Main.main(Main.java:587) "VM Thread" prio=5 tid=0x00a2b130 nid=0x69c runnable "VM Periodic Task Thread" prio=10 tid=0x00a336d8 nid=0xccc waiting on condition "Suspend Checker Thread" prio=10 tid=0x00a30428 nid=0x36c runnable
Jon Which build are you using? Your new stack trace is for a totally different problem and I want to check if it is the same as another problem.
This looks like a duplicate of Bug 42511 which was fixed post M3.
I agree this looks like a dup of bug 42511
This has still been happening to me while using integration build I20030917
Here's what's happening: - save operation is happening in the UI thread, using the status line progress monitor. - EventLoopProgressMonitor spins the event loop, which responds to the Ctrl+B key sequence, starting a build. - The build forks a ModalContext thread, and then blocks the UI thread until the ModalContext completes - The ModalContext tries to begin an operation, but core does not grant permission because another thread (main) is in the middle of an operation -> This causes deadlock. I reproduced quite easily by turning off autobuild, and then rapidly hitting Ctrl+B while the save was happening.
This is serious because many people have Ctrl+S, Ctrl+B built-in as a reflex. The save operation reports progress in the status line using IWorkbenchWindow.run(). This disables all controls in the shell except for the cancel button in the status line. Previously, this also disabled any keybindings in the window, since they were implemented using hidden menu items, and the menubar was disabled. Now that we're using the display filter mechanism, these events are coming through at inappropriate times. Could check to see whether the window's menubar is disabled in the key filter. Should use isEnabled() rather than getEnabled() in case the menubar is disabled indirectly due to a parent (i.e. the shell) being disabled.
Created attachment 6182 [details] possible solution A patch to Workbench and WorkbenchWindow. It disables the key filter at the same point it disables the toolbar. Adds more API to Workbench to expose the enabled state of the key filter. Maybe a more elegant solution than this?
*** Bug 44199 has been marked as a duplicate of this bug. ***
*** Bug 44218 has been marked as a duplicate of this bug. ***
*** Bug 44222 has been marked as a duplicate of this bug. ***
It would be really good to get fix into M4..
I had not noticed the problem until 20030930, and since then I get this 3 times a day... real pain, however I never lost any information since file got saved before the lock.
*** Bug 44241 has been marked as a duplicate of this bug. ***
Changing component
fixed. oct 7, 12:10p EST
*** Bug 44602 has been marked as a duplicate of this bug. ***
Reopening as this will require a new build submission
this was not fixed correctly. a patch has been applied and we will be doing a build submission. i want to keep this bug open because i believe there is another path to get this problem that i'd like to look into post M4 (no one has reported getting the bug along this path yet, but i think it may exist) as a reminder to myself, the problem may be this: aside from the key filter on display, we make use of another mechanism to trap keys - all single key-stroke key sequences that have a corresponding menu item have their key stroke registered as a real accelerator on that menu item. this is redundant to the display key filter but exists to allow for native UI affordances on menus when you press a shortcut key (like the mac menu 'blink', for instance). as the accelerator table should be hit before the key filter on display, ActionContributionItem will receive the key stroke in handleSelectionEvent. we should be careful not to run the Action corresponding to this ActionContributionItem if the keyboard should be disabled at this time. downgrading to minor for this remaining issue (if it even exists..)
I don't believe the above scenario is a problem. Running an operation in the status line progress monitor (i.e. the save) disables the menubar and all other controls in the shell (except for the cancel button). Disabling the menubar should disable accelerators on the menu items.
sounds good to me - closing as fixed.
I have verified that this fix is in build 200310101107 (M4 candidate)
*** Bug 46193 has been marked as a duplicate of this bug. ***
*** Bug 48651 has been marked as a duplicate of this bug. ***
