Comment 1 Dani Megert 2011-12-08 11:05:59 EST

Eddie, steps would be great. Also, can you provide the version of the 'org.eclipse.jdt.ui' bundle (simply paste the full name of the JAR inside the 'plugins' directory).

Comment 2 Eddie Galvez 2011-12-08 12:45:05 EST

No real "steps" per-se. I can tell you a bit more of context. I'm on a train with spotty wifi. I was in the team synch view. I have about 5 projects, SVN connected via subversive. I had an editor open, which IIRC I had just looked at via the compare editor, and then selected a string and hit ctrl-x. that's all.

org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800

Comment 3 Dominik Stadler 2012-01-11 08:49:31 EST

Isn't this Bug and Bug 160192 the same?

Comment 4 Dani Megert 2012-01-11 08:56:31 EST

(In reply to comment #3)
> Isn't this Bug and Bug 160192 the same?

160192 is not a deadlock.

Comment 5 Dani Megert 2012-01-26 03:16:18 EST

*** Bug 369662 has been marked as a duplicate of this bug. ***

Comment 6 William Saar 2012-03-07 03:55:53 EST

This bug hangs Eclipse for me (a thread dump while the application is hanging shows the same stack trace) on Windows XP soon after re-awakening my computer from stand by and editing previously open Java files. I run Eclipse using the JRockit JVM.

org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800.jar

Comment 7 Nick Mitchell 2012-03-19 18:05:45 EDT

When i install texclipse (texclipse.sourceforge.net) i see this problem very frequently in the Java editor.  i wouldn't have suspected that texclipse would modify the Java perspective... but, i only see the deadlock when i have texclipse (and pdfclipse) installed. i get the deadlock by editing, sometimes just by flying over certain pieces of text. 

32-bit 3.7.2 mac 10.6.8

Comment 8 Dani Megert 2012-04-12 09:03:23 EDT

*** Bug 376545 has been marked as a duplicate of this bug. ***

Comment 9 Markus Keller 2012-04-18 06:45:08 EDT

*** Bug 376919 has been marked as a duplicate of this bug. ***

Comment 10 Dani Megert 2012-08-02 03:49:04 EDT

*** Bug 386419 has been marked as a duplicate of this bug. ***

Comment 11 Lari Hotari 2012-08-22 14:11:10 EDT

Created attachment 220154 [details]
Threaddump of deadlock in SpringSource Tool Suite STS 3.0.0 (Eclipse Juno 4.2.0.v20120608-135145-9JF7BHV8FyMteji0Oi_ePMz0xuZ8TVo7lV0z0ecb)

similar problem in STS 3.0.0 . Deadlock after clipboard operations (cut / copy).

"main" prio=10 tid=0xf6705800 nid=0x7750 in Object.wait() [0xf6903000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0xc8a634c8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:503)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:457)
        - locked <0xc8a634c8> (a java.lang.Object)
        at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
        at org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.getClipboardData(ClipboardOperationAction.java:449)
        at org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.doCutCopyWithImportsOperation(ClipboardOperationAction.java:376)
        at org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.internalDoOperation(ClipboardOperationAction.java:330)
        at org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction$1.run(ClipboardOperationAction.java:278)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
        at org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.run(ClipboardOperationAction.java:276)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
        at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
        at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
        at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)



"Worker-18" prio=10 tid=0xa5119800 nid=0x77b9 in Object.wait() [0x9c7fc000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0xc8a634c8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:503)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:457)
        - locked <0xc8a634c8> (a java.lang.Object)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)
        at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:470)

Comment 12 Lari Hotari 2012-08-22 14:18:38 EDT

Created attachment 220157 [details]
Another STS 3.0.0 threaddump of deadlock after Clipboard copy

Comment 13 Lari Hotari 2012-08-23 01:36:25 EDT

I have disabled Java->Editor->Content Assist->Auto Activation and I don't anymore experience the crashes.

Comment 14 Dani Megert 2013-02-18 04:07:35 EST

*** Bug 401045 has been marked as a duplicate of this bug. ***

Comment 15 Peter Larsen 2013-02-18 14:32:31 EST

My eclipse froze after alt-tab to eclipse, ctrl-c, alt-tab away again. It did not copy anything to the clipboard.

Version: 4.3.0
Build id: I20130204-1400

Deadlock Detection:

No deadlocks found.

Thread 54: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=381, line=457 (Interpreted frame)
 - org.eclipse.jdt.ui.SharedASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=9, line=128 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.text.java.hover.NLSStringHover.internalGetHoverInfo(org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) @bci=28, line=135 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.text.java.hover.NLSStringHover.getHoverInfo2(org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) @bci=3, line=114 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion, boolean) @bci=67, line=163 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) @bci=4, line=129 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) @bci=26, line=85 (Interpreted frame)
 - org.eclipse.jface.text.TextViewerHoverManager$4.run() @bci=40, line=166 (Interpreted frame)


Thread 52: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=381, line=457 (Interpreted frame)
 - org.eclipse.jdt.ui.SharedASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=9, line=128 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jface.text.ITextSelection, org.eclipse.core.runtime.IProgressMonitor) @bci=18, line=170 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(org.eclipse.core.runtime.IProgressMonitor) @bci=35, line=155 (Interpreted frame)
 - org.eclipse.core.internal.jobs.Worker.run() @bci=23, line=53 (Compiled frame)


Thread 51: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 50: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - java.util.TimerThread.mainLoop() @bci=28 (Interpreted frame)
 - java.util.TimerThread.run() @bci=1 (Interpreted frame)


Thread 49: (state = IN_NATIVE)
 - java.lang.ProcessImpl.waitForInterruptibly(long) @bci=0 (Interpreted frame)
 - java.lang.ProcessImpl.waitFor() @bci=4 (Interpreted frame)
 - org.eclipse.debug.core.model.RuntimeProcess$ProcessMonitorThread.run() @bci=36, line=417 (Interpreted frame)


Thread 48: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.debug.internal.core.InputStreamMonitor.writeNext() @bci=101, line=154 (Interpreted frame)
 - org.eclipse.debug.internal.core.InputStreamMonitor.write() @bci=4, line=124 (Interpreted frame)
 - org.eclipse.debug.internal.core.InputStreamMonitor$1.run() @bci=4, line=99 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 47: (state = IN_NATIVE)
 - java.io.FileInputStream.readBytes(byte[], int, int) @bci=0 (Compiled frame; information may be imprecise)
 - java.io.FileInputStream.read(byte[], int, int) @bci=4 (Compiled frame)
 - java.io.BufferedInputStream.read1(byte[], int, int) @bci=39 (Compiled frame)
 - java.io.BufferedInputStream.read(byte[], int, int) @bci=49 (Compiled frame)
 - java.io.FilterInputStream.read(byte[]) @bci=5 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor.read() @bci=39, line=145 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor.access$1(org.eclipse.debug.internal.core.OutputStreamMonitor) @bci=1, line=135 (Interpreted frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor$1.run() @bci=4, line=208 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 46: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Compiled frame)
 - org.eclipse.ui.internal.console.IOConsolePartitioner.streamAppended(org.eclipse.ui.console.IOConsoleOutputStream, java.lang.String) @bci=151, line=471 (Compiled frame)
 - org.eclipse.ui.console.IOConsoleOutputStream.notifyParitioner(java.lang.String) @bci=6, line=242 (Compiled frame)
 - org.eclipse.ui.console.IOConsoleOutputStream.encodedWrite(java.lang.String) @bci=81, line=237 (Compiled frame)
 - org.eclipse.ui.console.IOConsoleOutputStream.write(byte[], int, int) @bci=22, line=195 (Compiled frame)
 - org.eclipse.ui.console.IOConsoleOutputStream.write(byte[]) @bci=5, line=205 (Compiled frame)
 - org.eclipse.debug.internal.ui.views.console.ProcessConsole$StreamListener.streamAppended(java.lang.String, org.eclipse.debug.core.model.IStreamMonitor) @bci=46, line=589 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor$ContentNotifier.run() @bci=12, line=258 (Compiled frame)
 - org.eclipse.core.runtime.SafeRunner.run(org.eclipse.core.runtime.ISafeRunnable) @bci=5, line=42 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor$ContentNotifier.notifyAppend(java.lang.String) @bci=37, line=268 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor.fireStreamAppended(java.lang.String) @bci=5, line=117 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor.read() @bci=114, line=157 (Compiled frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor.access$1(org.eclipse.debug.internal.core.OutputStreamMonitor) @bci=1, line=135 (Interpreted frame)
 - org.eclipse.debug.internal.core.OutputStreamMonitor$1.run() @bci=4, line=208 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 45: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.ui.console.IOConsoleInputStream.waitForData() @bci=4, line=147 (Interpreted frame)
 - org.eclipse.ui.console.IOConsoleInputStream.read(byte[], int, int) @bci=1, line=92 (Interpreted frame)
 - org.eclipse.ui.console.IOConsoleInputStream.read(byte[]) @bci=5, line=117 (Interpreted frame)
 - org.eclipse.debug.internal.ui.views.console.ProcessConsole$InputReadJob.run(org.eclipse.core.runtime.IProgressMonitor) @bci=28, line=680 (Interpreted frame)
 - org.eclipse.core.internal.jobs.Worker.run() @bci=23, line=53 (Compiled frame)


Thread 44: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.core.internal.jobs.WorkerPool.sleep(long) @bci=52, line=188 (Compiled frame)
 - org.eclipse.core.internal.jobs.WorkerPool.startJob(org.eclipse.core.internal.jobs.Worker) @bci=78, line=220 (Compiled frame)
 - org.eclipse.core.internal.jobs.Worker.run() @bci=318, line=50 (Compiled frame)


Thread 43: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=381, line=457 (Interpreted frame)
 - org.eclipse.jdt.ui.SharedASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=9, line=128 (Interpreted frame)
 - org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(org.eclipse.jdt.core.IMethod) @bci=10, line=161 (Interpreted frame)
 - org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(java.lang.Object) @bci=61, line=136 (Interpreted frame)
 - org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorate(java.lang.Object, org.eclipse.jface.viewers.IDecoration) @bci=2, line=273 (Interpreted frame)
 - org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(java.lang.Object, org.eclipse.jface.viewers.IDecoration) @bci=83, line=269 (Compiled frame)
 - org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run() @bci=12, line=81 (Compiled frame)
 - org.eclipse.core.runtime.SafeRunner.run(org.eclipse.core.runtime.ISafeRunnable) @bci=5, line=42 (Compiled frame)
 - org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(java.lang.Object, org.eclipse.ui.internal.decorators.DecorationBuilder, org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition) @bci=14, line=365 (Compiled frame)
 - org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(java.lang.Object, org.eclipse.ui.internal.decorators.DecorationBuilder) @bci=29, line=347 (Compiled frame)
 - org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(java.lang.Object, boolean, org.eclipse.jface.viewers.IDecorationContext) @bci=87, line=371 (Compiled frame)
 - org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(org.eclipse.core.runtime.IProgressMonitor) @bci=146, line=331 (Compiled frame)
 - org.eclipse.core.internal.jobs.Worker.run() @bci=23, line=53 (Compiled frame)


Thread 42: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 41: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 40: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 39: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.core.internal.jobs.WorkerPool.sleep(long) @bci=52, line=188 (Compiled frame)
 - org.eclipse.core.internal.jobs.WorkerPool.startJob(org.eclipse.core.internal.jobs.Worker) @bci=78, line=220 (Compiled frame)
 - org.eclipse.core.internal.jobs.Worker.run() @bci=318, line=50 (Compiled frame)


Thread 38: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 37: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 36: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 35: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 34: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 33: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 32: (state = IN_NATIVE)
 - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise)
 - java.net.SocketInputStream.read(byte[], int, int, int) @bci=79 (Compiled frame)
 - java.net.SocketInputStream.read(byte[], int, int) @bci=11 (Compiled frame)
 - com.jcraft.jsch.IO.getByte(byte[], int, int) @bci=7, line=82 (Compiled frame)
 - com.jcraft.jsch.Session.read(com.jcraft.jsch.Buffer) @bci=22, line=854 (Compiled frame)
 - com.jcraft.jsch.Session.run() @bci=86, line=1295 (Compiled frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 31: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44 (Compiled frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2 (Compiled frame)
 - org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run() @bci=10, line=1122 (Interpreted frame)


Thread 30: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run() @bci=83, line=179 (Compiled frame)


Thread 29: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.wst.jsdt.internal.core.search.processing.JobManager.run() @bci=86, line=370 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 26: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Compiled frame)
 - org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run() @bci=328, line=106 (Compiled frame)


Thread 25: (state = IN_NATIVE)
 - java.net.DualStackPlainSocketImpl.accept0(int, java.net.InetSocketAddress[]) @bci=0 (Interpreted frame)
 - java.net.DualStackPlainSocketImpl.socketAccept(java.net.SocketImpl) @bci=37 (Interpreted frame)
 - java.net.AbstractPlainSocketImpl.accept(java.net.SocketImpl) @bci=7 (Interpreted frame)
 - java.net.PlainSocketImpl.accept(java.net.SocketImpl) @bci=35 (Interpreted frame)
 - java.net.ServerSocket.implAccept(java.net.Socket) @bci=60 (Interpreted frame)
 - java.net.ServerSocket.accept() @bci=48 (Interpreted frame)
 - com.yourkit.b.e$1.run() @bci=4, line=26 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 24: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.jdt.internal.core.search.processing.JobManager.run() @bci=86, line=382 (Interpreted frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 22: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent() @bci=4, line=400 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run() @bci=1, line=336 (Interpreted frame)


Thread 21: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.core.internal.jobs.InternalWorker.run() @bci=135, line=58 (Interpreted frame)


Thread 20: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent() @bci=4, line=400 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run() @bci=1, line=336 (Interpreted frame)


Thread 19: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.equinox.internal.util.impl.tpt.timer.TimerImpl.run() @bci=506, line=141 (Compiled frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 18: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent() @bci=4, line=400 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run() @bci=1, line=336 (Interpreted frame)


Thread 17: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent() @bci=4, line=400 (Interpreted frame)
 - org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run() @bci=1, line=336 (Interpreted frame)


Thread 16: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - org.eclipse.osgi.framework.internal.core.Framework.run() @bci=11, line=1862 (Compiled frame)
 - java.lang.Thread.run() @bci=11 (Interpreted frame)


Thread 10: (state = BLOCKED)


Thread 9: (state = BLOCKED)


Thread 8: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44 (Compiled frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2 (Compiled frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3 (Compiled frame)


Thread 7: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Compiled frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=46 (Compiled frame)


Thread 1: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=381, line=457 (Interpreted frame)
 - org.eclipse.jdt.ui.SharedASTProvider.getAST(org.eclipse.jdt.core.ITypeRoot, org.eclipse.jdt.ui.SharedASTProvider$WAIT_FLAG, org.eclipse.core.runtime.IProgressMonitor) @bci=9, line=128 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.getClipboardData(org.eclipse.jdt.core.ITypeRoot, int, int) @bci=5, line=449 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.doCutCopyWithImportsOperation() @bci=81, line=376 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.internalDoOperation() @bci=36, line=330 (Interpreted frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction$1.run() @bci=4, line=278 (Interpreted frame)
 - org.eclipse.swt.custom.BusyIndicator.showWhile(org.eclipse.swt.widgets.Display, java.lang.Runnable) @bci=116, line=70 (Compiled frame)
 - org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.run() @bci=53, line=276 (Interpreted frame)
 - org.eclipse.jface.action.Action.runWithEvent(org.eclipse.swt.widgets.Event) @bci=1, line=499 (Interpreted frame)
 - org.eclipse.jface.commands.ActionHandler.execute(org.eclipse.core.commands.ExecutionEvent) @bci=73, line=119 (Interpreted frame)
 - org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(org.eclipse.e4.core.contexts.IEclipseContext, java.util.Map, org.eclipse.swt.widgets.Event, org.eclipse.core.expressions.IEvaluationContext) @bci=107, line=76 (Interpreted frame)
 - sun.reflect.GeneratedMethodAccessor20.invoke(java.lang.Object, java.lang.Object[]) @bci=64 (Interpreted frame)
 - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6 (Compiled frame)
 - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=57 (Compiled frame)
 - org.eclipse.e4.core.internal.di.MethodRequestor.execute() @bci=84, line=56 (Compiled frame)
 - org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(java.lang.Object, java.lang.Class, java.lang.Class, java.lang.Object, org.eclipse.e4.core.di.suppliers.PrimaryObjectSupplier, org.eclipse.e4.core.di.suppliers.PrimaryObjectSupplier, boolean) @bci=104, line=231 (Compiled frame)
 - org.eclipse.e4.core.internal.di.InjectorImpl.invoke(java.lang.Object, java.lang.Class, java.lang.Object, org.eclipse.e4.core.di.suppliers.PrimaryObjectSupplier, org.eclipse.e4.core.di.suppliers.PrimaryObjectSupplier) @bci=13, line=212 (Compiled frame)
 - org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(java.lang.Object, java.lang.Class, org.eclipse.e4.core.contexts.IEclipseContext, org.eclipse.e4.core.contexts.IEclipseContext, java.lang.Object) @bci=29, line=131 (Compiled frame)
 - org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(org.eclipse.core.commands.ParameterizedCommand, org.eclipse.e4.core.contexts.IEclipseContext) @bci=118, line=171 (Interpreted frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(org.eclipse.core.commands.ParameterizedCommand, org.eclipse.swt.widgets.Event) @bci=66, line=277 (Interpreted frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(java.util.List, org.eclipse.swt.widgets.Event) @bci=77, line=496 (Compiled frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(java.util.List, org.eclipse.swt.widgets.Event) @bci=14, line=547 (Interpreted frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(org.eclipse.swt.widgets.Event) @bci=172, line=368 (Interpreted frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher, org.eclipse.swt.widgets.Event) @bci=2, line=314 (Interpreted frame)
 - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(org.eclipse.swt.widgets.Event) @bci=13, line=83 (Interpreted frame)
 - org.eclipse.swt.widgets.EventTable.sendEvent(org.eclipse.swt.widgets.Event) @bci=214, line=84 (Compiled frame)
 - org.eclipse.swt.widgets.Display.filterEvent(org.eclipse.swt.widgets.Event) @bci=12, line=1262 (Compiled frame)
 - org.eclipse.swt.widgets.Widget.sendEvent(org.eclipse.swt.widgets.Event) @bci=7, line=1052 (Compiled frame)
 - org.eclipse.swt.widgets.Widget.sendEvent(int, org.eclipse.swt.widgets.Event, boolean) @bci=73, line=1077 (Compiled frame)
 - org.eclipse.swt.widgets.Widget.sendEvent(int, org.eclipse.swt.widgets.Event) @bci=4, line=1062 (Compiled frame)
 - org.eclipse.swt.widgets.Widget.sendKeyEvent(int, int, long, long, org.eclipse.swt.widgets.Event) @bci=4, line=1104 (Interpreted frame)
 - org.eclipse.swt.widgets.Widget.sendKeyEvent(int, int, long, long) @bci=32, line=1100 (Interpreted frame)
 - org.eclipse.swt.widgets.Widget.wmChar(long, long, long) @bci=66, line=1521 (Interpreted frame)
 - org.eclipse.swt.widgets.Control.WM_CHAR(long, long) @bci=7, line=4640 (Interpreted frame)
 - org.eclipse.swt.widgets.Canvas.WM_CHAR(long, long) @bci=3, line=344 (Interpreted frame)
 - org.eclipse.swt.widgets.Control.windowProc(long, int, long, long) @bci=1868, line=4614 (Compiled frame)
 - org.eclipse.swt.widgets.Canvas.windowProc(long, int, long, long) @bci=46, line=340 (Compiled frame)
 - org.eclipse.swt.widgets.Display.windowProc(long, long, long, long) @bci=271, line=4976 (Compiled frame)
 - org.eclipse.swt.internal.win32.OS.DispatchMessageW(org.eclipse.swt.internal.win32.MSG) @bci=0 (Compiled frame)
 - org.eclipse.swt.internal.win32.OS.DispatchMessage(org.eclipse.swt.internal.win32.MSG) @bci=7, line=2546 (Compiled frame)
 - org.eclipse.swt.widgets.Display.readAndDispatch() @bci=64, line=3756 (Compiled frame)
 - org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run() @bci=638, line=1057 (Compiled frame)
 - org.eclipse.core.databinding.observable.Realm.runWithDefault(org.eclipse.core.databinding.observable.Realm, java.lang.Runnable) @bci=12, line=332 (Interpreted frame)
 - org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(org.eclipse.e4.ui.model.application.MApplicationElement, org.eclipse.e4.core.contexts.IEclipseContext) @bci=57, line=941 (Interpreted frame)
 - org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(org.eclipse.e4.ui.model.application.MApplicationElement) @bci=20, line=79 (Interpreted frame)
 - org.eclipse.ui.internal.Workbench$5.run() @bci=256, line=588 (Interpreted frame)
 - org.eclipse.core.databinding.observable.Realm.runWithDefault(org.eclipse.core.databinding.observable.Realm, java.lang.Runnable) @bci=12, line=332 (Interpreted frame)
 - org.eclipse.ui.internal.Workbench.createAndRunWorkbench(org.eclipse.swt.widgets.Display, org.eclipse.ui.application.WorkbenchAdvisor) @bci=18, line=543 (Interpreted frame)
 - org.eclipse.ui.PlatformUI.createAndRunWorkbench(org.eclipse.swt.widgets.Display, org.eclipse.ui.application.WorkbenchAdvisor) @bci=2, line=149 (Interpreted frame)
 - org.eclipse.ui.internal.ide.application.IDEApplication.start(org.eclipse.equinox.app.IApplicationContext) @bci=108, line=124 (Interpreted frame)
 - org.eclipse.equinox.internal.app.EclipseAppHandle.run(java.lang.Object) @bci=135, line=196 (Interpreted frame)
 - org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(java.lang.Object) @bci=103, line=110 (Interpreted frame)
 - org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(java.lang.Object) @bci=29, line=79 (Interpreted frame)
 - org.eclipse.core.runtime.adaptor.EclipseStarter.run(java.lang.Object) @bci=119, line=354 (Interpreted frame)
 - org.eclipse.core.runtime.adaptor.EclipseStarter.run(java.lang.String[], java.lang.Runnable) @bci=183, line=181 (Interpreted frame)
 - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame)
 - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=87 (Interpreted frame)
 - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6 (Interpreted frame)
 - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=57 (Interpreted frame)
 - org.eclipse.equinox.launcher.Main.invokeFramework(java.lang.String[], java.net.URL[]) @bci=211, line=636 (Interpreted frame)
 - org.eclipse.equinox.launcher.Main.basicRun(java.lang.String[]) @bci=126, line=591 (Interpreted frame)
 - org.eclipse.equinox.launcher.Main.run(java.lang.String[]) @bci=4, line=1450 (Interpreted frame)
 - org.eclipse.equinox.launcher.Main.main(java.lang.String[]) @bci=10, line=1426 (Interpreted frame)

Comment 16 Dani Megert 2013-03-20 13:16:38 EDT

*** Bug 403885 has been marked as a duplicate of this bug. ***

Comment 17 Brian Brooks 2013-04-09 15:28:51 EDT

I encountered this bug as well.  The relevant threads are...

 "Worker-3571" prio=6 tid=0x00000000114b7800 nid=0x964 waiting for monitor entry [0x000000002a45f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- waiting to lock <0x00000000f7490ce8> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

   Locked ownable synchronizers:
	- None

"Worker-3568" prio=6 tid=0x00000000114b9000 nid=0x2984 waiting for monitor entry [0x000000002958f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- waiting to lock <0x00000000f7490ce8> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

   Locked ownable synchronizers:
	- None

"Worker-3570" prio=6 tid=0x00000000114bc000 nid=0x1980 in Object.wait() [0x000000002998f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:503)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:457)
	- locked <0x00000000e10979a0> (a java.lang.Object)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- locked <0x00000000f7490ce8> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

   Locked ownable synchronizers:
	- None

Comment 18 Brian Brooks 2013-04-09 15:36:36 EDT

I'm running the latest Eclipse Juno as of late March 2013 (all Juno updates have been applied via Help menu).  The problem occurred after heavily using Eclipse for 5 days i.e. opening and closing >30 .java files, launching debug configurations.  By day 5 Eclipse had gotten quite sluggish and just before the deadlock, I got a prompt about content assist taking too long.  I had clicked OK on that dialog and soon after while trying to copy and paste some text, the IDE froze (spinning cursor on Windows 7 64-bit).  JDK version is 1.7 update 15.

Comment 19 Dani Megert 2013-05-23 05:30:18 EDT

I tried to reproduce the deadlock this morning without luck and could not find an obvious bug in the code.

Comment 20 Dani Megert 2013-06-25 06:28:48 EDT

*** Bug 411504 has been marked as a duplicate of this bug. ***

Comment 21 Markus Keller 2013-12-06 14:29:05 EST

Created attachment 238130 [details]
copy of Debug view

I ran into the deadlock in a runtime workbench. As you can see in the attached text from the Debug view, Thread [main] and Thread [Worker-70] are

			waiting for: Object  (id=14884)	

but no thread holds that lock and no thread looks like it will make any progress without that lock.

Unfortunately, nobody understands the synchronization code. But I found at least one unsafe coding pattern: The second invocation of ASTProvider#isReconciling(ITypeRoot) is not in a "synchronized (fReconcileLock)" block, and the implementation accesses two shared variables:
- fIsReconciling has once been made volatile (without any explanation)
- fReconcilingJavaElement is not volatile

I've made fReconcilingJavaElement volatile as well.


Since a deadlock is unacceptable, I've also added a 30 seconds timeout to the wait call. A reconcile operation should never take that long, and if it does, then everything is better than a deadlock.

http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=49d9247ac4323fabfd146561c594dcf9405e3aa0

Comment 22 Dani Megert 2014-03-05 03:00:35 EST

*** Bug 429558 has been marked as a duplicate of this bug. ***

Comment 23 Mauro Molinari 2014-03-05 03:53:45 EST

(In reply to Markus Keller from comment #21)
> I ran into the deadlock in a runtime workbench. As you can see in the
> attached text from the Debug view, Thread [main] and Thread [Worker-70] are
> 
> 			waiting for: Object  (id=14884)	
> 
> but no thread holds that lock and no thread looks like it will make any
> progress without that lock.
> 
> Unfortunately, nobody understands the synchronization code. But I found at
> least one unsafe coding pattern: The second invocation of
> ASTProvider#isReconciling(ITypeRoot) is not in a "synchronized
> (fReconcileLock)" block, and the implementation accesses two shared
> variables:

I do not think the problem is in there, my dump in bug #429558 shows that part of code is not involved in the deadlock threads.
Also, regarding the lock which is not hold by any thread... I don't know if it can be useful or not (maybe I don't just understand the dumps correctly), but I noticed the following when I took the thread dump in my case:
- the dump taken with Java VisualVM shows pairs of "waiting on <lock>" and "locked <lock>" rows for the threads I think are deadlocked
- the same thread information taken with jConsole does not showed the "locked" part for those threads and the deadlock detection button does not find any deadlock

In bug #429558 I attached the dump taken with Java VisualVM and the hotspot seems to be the following for three threads (main, Worker-20 and "Text Viewer Hover Presenter" - since main was blocked, the UI was frozen):

   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x000000077ab378f8> (a java.lang.Object)
	at java.lang.Object.wait(Object.java:503)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:457)
	- locked <0x000000077ab378f8> (a java.lang.Object)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)

Comment 24 Dani Megert 2014-05-29 08:32:15 EDT

*** Bug 434214 has been marked as a duplicate of this bug. ***

Comment 25 Stephan Herrmann 2014-11-17 11:54:15 EST

Created attachment 248705 [details]
variant deadlock

Happened again, this time three parties seem to be deadlocked on ASTProvider:

- JavaEditorTextHoverProxy
- OverrideIndicatorLabelDecorator
- ClipboardOperationAction

One particular observation piqued my curiosity:
In each of the three threads involved, the number of recursive calls (line 470) is slowly growing over time. Some timeout triggering deeper recursion instead of abort??

Comment 26 Tobias Oberlies 2015-02-16 10:49:43 EST

Created attachment 250832 [details]
deadlock with really long getAST recursion

(In reply to Stephan Herrmann from comment #25)
> Happened again, this time three parties seem to be deadlocked on ASTProvider:
> 
> - JavaEditorTextHoverProxy
> - OverrideIndicatorLabelDecorator
> - ClipboardOperationAction
> 
> One particular observation piqued my curiosity:
> In each of the three threads involved, the number of recursive calls (line
> 470) is slowly growing over time. Some timeout triggering deeper recursion
> instead of abort??

Added another stack dump. The number of getAST calls seems to grow without limit.

In my case, the callers that are locked are
- NLSStringHover
- SelectionListenerWithASTManager$PartListenerGroup
- OverrideIndicatorLabelDecorator
- ClipboardOperationAction (UI thread)

Comment 27 Stephan Herrmann 2015-02-16 18:46:18 EST

IIRC, I recently observed the same stack growing over time (using jvisualvm). I don't have the stacktrace here to check. From memory the speed of stack growth would pretty well correspond to the 30sec timeout added in comment 21. And indeed: when the timeout triggers, next thing we do is the recursive call. 

More observations:

- isActiveElement is initialized in a synchronized block, but still used after that block. Is the value still reliable outside the sync.block?

- similar for isReconciling. Maybe reconciled() got called after the synchronized (fReconcileLock) block, but before entering the fWaitLock.wait(30000). Couldn't that mean, the notifyAll() happened before it's awaited, thus the real wait will never see it?

- comparison is inconsistent between 
    input.equals(fActiveJavaElement)
  vs.
    activeElement == fActiveJavaElement

Comment 28 Heiko Selber 2015-03-26 07:04:01 EDT

I observe the same bug occasionally (up to once per day) with Luna on Ubuntu 14.04 with Oracle JDK 1.7.0_76.

I guess it happens only when I copy text in a fairly large Java file (2000+ lines) AND immediately scroll through it.

I can provide thread dumps if necessary.

Installation Details:

Eclipse Java EE IDE for Web Developers.
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600

Comment 29 Stefan Xenos 2015-07-21 13:43:36 EDT

It seems to me as though a possible sequence of events to reproduce this is:

1. ASTProvider receives an aboutToBeReconciled(ITypeRoot) call -- probably triggered from AbstractReconciler.Listener#documentChanged(DocumentEvent), which makes this call but doesn't immediately start reconciliation. This would set up the member variables in such a manner as to cause a subsequent call to getAST to block.

2. From the UI thread, an editor calls ASTProvider#getAST(ITypeRoot, WAIT_FLAG, IProgressMonitor) -- it gets stuck in the call to wait() at the stack trace we've seen attached to this bug.

3. The UI thread is now blocked, so it won't make any of the calls to things like ASTProvider's ActivationListener, which would have triggered cancellation and a call to fWaitLock.notifyAll().

4. At this point, the only code path that can possibly wake up the UI thread would be a call to ASTProvider#reconciled from a background thread.. and it seems as though this call never arrives. All other calls to notifyAll() rely on the UI thread.

I looked back at callers of reconciled. If we're relying on paired calls to aboutToBeReconciled / reconciled in order to wake up the UI thread, they two calls would need to be quite closely coupled in a pattern like this:

aboutToBeReconciled(...)
try {
  do something
} finally {
  reconciled()
}

...and the callers don't look anything like that. Reconciled is often called from event handlers that aren't closely connected to the call to aboutToBeReconciled.

Comment 30 Stefan Xenos 2015-07-21 15:15:35 EDT

I've tried putting a breakpoint at the start of the ASTProvider.reconciled method in order to see what happens to the UI thread if the reconciled method call is omitted (or in this case, paused indefinitely).

The resulting behavior is consistent with the behaviors described here -- the UI thread locks up with a stack trace identical to the the one here when you use the keybinding for "cut".

Of course, everything resumes fine when you resume the thread that invokes "reconciled"... but it does look like an omitted call to "reconciled"

Comment 31 Stephan Herrmann 2016-01-06 11:43:39 EST

After long time, I'm seeing this again. Last actions: while a remote debug session was running, I selected a method name and hit F3. Nothing fancy. UI froze, and freeze persisted after I closed the debug target.

Two threads are growing deeper recursion over time:

...
at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:461)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:461)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)


...
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:461)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:461)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.text.java.hover.NLSStringHover.internalGetHoverInfo(NLSStringHover.java:135)
	at org.eclipse.jdt.internal.ui.text.java.hover.NLSStringHover.getHoverInfo2(NLSStringHover.java:114)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:163)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:129)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:85)
	at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166)



Another thread is blocked at

   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.jdt.internal.core.JavaModelManager.getWorkingCopies(JavaModelManager.java:2595)
	- waiting to lock <0x00000000c3d5dfe0> (a java.util.HashMap)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:66)
	at org.eclipse.jdt.internal.core.CancelableNameEnvironment.<init>(CancelableNameEnvironment.java:26)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:686)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1207)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:826)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:535)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:528)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:471)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- locked <0x00000000cea49d80> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Another one at:
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.jdt.internal.core.JavaModelManager.getWorkingCopies(JavaModelManager.java:2595)
	- waiting to lock <0x00000000c3d5dfe0> (a java.util.HashMap)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:66)
	at org.eclipse.jdt.internal.core.JavaProject.newSearchableNameEnvironment(JavaProject.java:2406)
	at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:149)
	at org.eclipse.jdt.internal.core.ClassFile.codeSelect(ClassFile.java:191)
	at org.eclipse.jdt.internal.core.ClassFile.codeSelect(ClassFile.java:180)
	at org.eclipse.jdt.internal.ui.actions.SelectionConverter.codeResolve(SelectionConverter.java:273)
	at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable.run(SelectionConverter.java:257)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)



And some more (currently 8) threads like:

   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	- waiting to lock <0x00000000cea49d80> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Comment 32 Thierry BLIND 2017-03-16 16:25:47 EDT

Hi,
I just wanted to add my own comment here. I delayed this work many times, and I thought it would be nice to add some patch for Oxygen ;)
In PDT we also have an ASTProvider class, which is very similar with the JSDT and JDT ones.
1 or 2 years ago I found a possible deadlock in our ASTProvider class (with lot of patience and difficulty !), this deadlock is most likely also possible in JSDT and JDT. Even if only theoretical...
I don't say it will solve all (or even any) cases described by this bug report, but I think it's always worth to correct bugs ;)

I'll send a patch and add some comment inside.

Thierry.

NB: also forgive me if my memories about this bug are not so fresh, it's old work now ;)

Comment 33 Eclipse Genie 2017-03-16 16:32:49 EDT

New Gerrit change created: https://git.eclipse.org/r/93252

Comment 34 Stephan Herrmann 2017-03-18 09:19:44 EDT

Created attachment 267332 [details]
stacks from yet another freeze

Unfortunately, I didn't run with debug enabled when it happened this time.

I made a note in bug 392738 for the JDT/Debug part.

OTOH, it once more shows that the timeout added here (comment 21) just changed the deadlock into infinite recursive retries. Maybe a true deadlock would actually be easier to analyse? Just guessing.

Comment 35 Thierry BLIND 2017-03-18 13:35:08 EDT

(In reply to Stephan Herrmann from comment #34)
> Created attachment 267332 [details]
> stacks from yet another freeze
> 
> Unfortunately, I didn't run with debug enabled when it happened this time.
> 
> I made a note in bug 392738 for the JDT/Debug part.
> 
> OTOH, it once more shows that the timeout added here (comment 21) just
> changed the deadlock into infinite recursive retries. Maybe a true deadlock
> would actually be easier to analyse? Just guessing.

Did you try to apply my patch and see if it changes something? :)

Comment 36 Stephan Herrmann 2017-03-18 13:47:10 EDT

(In reply to Thierry BLIND from comment #35)
> (In reply to Stephan Herrmann from comment #34)
> > Created attachment 267332 [details]
> > stacks from yet another freeze
> > 
> > Unfortunately, I didn't run with debug enabled when it happened this time.
> > 
> > I made a note in bug 392738 for the JDT/Debug part.
> > 
> > OTOH, it once more shows that the timeout added here (comment 21) just
> > changed the deadlock into infinite recursive retries. Maybe a true deadlock
> > would actually be easier to analyse? Just guessing.
> 
> Did you try to apply my patch and see if it changes something? :)

Sorry, but no.
This was a stock Oxygen M5 installation.
Unfortunately, this bug cannot be forcefully reproduced (can it?), so usually when it is observed it's already too late for any experimentation.

For lack of ability to debug this, can you reason, how your proposed patch relates to the exact freezes reported here? In particular: could any of your observations explain why the change from comment 21 modified the deadlock into this increasing-stack pattern of infinite retries?

If we have good reasons to believe that the patch fixes a real issue, without causing new problems, we could well give it a chance in real life. But without any evidence behind, we may want to wait until early 4.8 for pushing this to master.

Comment 37 Thierry BLIND 2017-03-18 17:03:30 EDT

(In reply to Stephan Herrmann from comment #36)
> (In reply to Thierry BLIND from comment #35)
> > (In reply to Stephan Herrmann from comment #34)
> > > Created attachment 267332 [details]
> > > stacks from yet another freeze
> > > 
> > > Unfortunately, I didn't run with debug enabled when it happened this time.
> > > 
> > > I made a note in bug 392738 for the JDT/Debug part.
> > > 
> > > OTOH, it once more shows that the timeout added here (comment 21) just
> > > changed the deadlock into infinite recursive retries. Maybe a true deadlock
> > > would actually be easier to analyse? Just guessing.
> > 
> > Did you try to apply my patch and see if it changes something? :)
> 
> Sorry, but no.
> This was a stock Oxygen M5 installation.
> Unfortunately, this bug cannot be forcefully reproduced (can it?), so
> usually when it is observed it's already too late for any experimentation.
> 
> For lack of ability to debug this, can you reason, how your proposed patch
> relates to the exact freezes reported here? In particular: could any of your
> observations explain why the change from comment 21 modified the deadlock
> into this increasing-stack pattern of infinite retries?
> 
> If we have good reasons to believe that the patch fixes a real issue,
> without causing new problems, we could well give it a chance in real life.
> But without any evidence behind, we may want to wait until early 4.8 for
> pushing this to master.

I will speak a little bit technical ;)
If I remember enough about the locking system used in ASTProvider, the "fWaitLock.wait(30000);" patch was to avoid waiting indefinitely on a "fWaitLock.notifyAll();" that never happened, so that was just a bad timing/ordering locking logic workaround (which is the real bug). Sadly, after hitting the 30 seconds lock timeout, there is still no guaranty that (meanwhile) fAST was calculated and not null (because the fAST calculation maybe never started!).
That's why you can still recurse indefinitely in "getAST(input, waitFlag, progressMonitor)" under certain specific circumstances (I think when input is reconciling, wait flag is WAIT_YES and fAST is null).

My patch avoids an additional bug, when fAST was correctly retrieved (fAST != null) BUT was reset to null too early, because the actual code didn't respect some held lock. It could also result in an infinite recursion of "getAST(input, waitFlag, progressMonitor)".

If I asked to test, it was just to know if you did hit the bug that my patch solves, or if you did hit previous described bug ;)

I think that this class should somehow be rewritten, because:
- locking system is too complicated, nobody seems to understand it correctly (me included)
- there are false assumptions here, for example that fAST calculation always started before the "fWaitLock.wait(30000)" part
- there can be infinite method recursions! No way to break out such loops actually

Hope my explanations were clear enough ;) And no hurry to merge my patch, since it doesn't solve main problems here ;)

Comment 38 Alexander Rathai 2017-04-27 05:55:38 EDT

Created attachment 268037 [details]
Yet another Freeze on COPY Neon.3 Release (4.6.3) 20170314-1500 org.eclipse.jdt.feature.group 3.12.3.v20170301-0400

I can currently reproduce this 100% when adding specific code and then issuing a copy (via strg+v or the context menu).

Comment 39 Alexander Rathai 2017-05-02 10:16:16 EDT

(In reply to Alexander Rathai from comment #38)
Not reproducible with
org.eclipse.jdt.feature.group 3.13.0.v20170308-2105

Comment 40 Donat Csikos 2017-12-05 14:50:06 EST

FYI an analysis of the problem: https://www.youtube.com/watch?v=Oi6-pXX11qw&feature=youtu.be&t=1929

Comment 41 Stephan Herrmann 2018-02-26 17:33:48 EST

*** Bug 531663 has been marked as a duplicate of this bug. ***

Comment 42 Stephan Herrmann 2018-02-26 17:51:29 EST

FYI, as of Bug 506239, the relevant part of ASTProvider has been moved to org.eclipse.jdt.core.manipulation.CoreASTProvider in plugin org.eclipse.jdt.core.manipulation.

(In reply to Donat Csikos from comment #40)
> FYI an analysis of the problem:
> https://www.youtube.com/watch?v=Oi6-pXX11qw&feature=youtu.be&t=1929

Interesting link, BUT, can anybody argue how a spurious wakeup could possibly produce the problem discussed here (as the video seems to suggest)?

I could only imagine one spurious wakeup to cause one unnecessary recursion, but nothing akin to deadlock, livelock or any such.

Comment 43 Sarika Sinha 2019-01-10 22:31:21 EST

*** Bug 543329 has been marked as a duplicate of this bug. ***

Comment 44 Andreas Höhmann 2019-03-15 04:36:59 EDT

Hi folks,
I come here to the issue via search for "JavaReconciler hangs" :) Because this actually happens here in my eclipse right now :) So I want to share my situation with you. Maybe it helps to figure out why.

I will attach a screenshot too ...
where you can see what I did in the java-editor ... I simply selected some text and (as far as I remember) I want to cut it out ... then eclipse hangs

Here is the thread-dump from visual vm

org.eclipse.jdt.internal.ui.text.JavaReconciler" #526 daemon prio=1 os_prio=-2 tid=0x000000006e8af800 nid=0x16d8 runnable [0x0000000071b6c000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.internal.compiler.parser.Scanner.isInModuleDeclaration(Scanner.java:2561)
        at org.eclipse.jdt.internal.compiler.parser.Scanner.getNextToken(Scanner.java:1171)
        at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:11648)
        at org.eclipse.jdt.internal.compiler.parser.Parser.parseExpression(Parser.java:12239)
        at org.eclipse.jdt.internal.compiler.ast.ReferenceExpression.copy(ReferenceExpression.java:152)
        at org.eclipse.jdt.internal.compiler.ast.ReferenceExpression.cachedResolvedCopy(ReferenceExpression.java:948)
        at org.eclipse.jdt.internal.compiler.ast.ReferenceExpression.isCompatibleWith(ReferenceExpression.java:1231)
        at org.eclipse.jdt.internal.compiler.lookup.PolyTypeBinding.isCompatibleWith(PolyTypeBinding.java:43)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:4917)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:4884)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:867)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:794)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod0(Scope.java:1750)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1651)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2934)
        at org.eclipse.jdt.internal.compiler.ast.MessageSend.findMethodBinding(MessageSend.java:954)
        at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:775)
        at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:1034)
        at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:641)
        at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:316)
        at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:551)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1229)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1354)
        at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:652)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1055)
        at org.eclipse.ajdt.core.parserbridge.AJCompilationUnitProblemFinder.processAJ(AJCompilationUnitProblemFinder.java:236)
        at org.eclipse.ajdt.ui.AJDTNameEnvironmentProvider.problemFind(AJDTNameEnvironmentProvider.java:79)
        at org.eclipse.contribution.jdt.itdawareness.ITDAwarenessAspect.ajc$around$org_eclipse_contribution_jdt_itdawareness_ITDAwarenessAspect$4$8b05d765(ITDAwarenessAspect.aj:234)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:247)
        at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:194)
        at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:268)
        at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:596)
        at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1145)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:173)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94)
        at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736)
        at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802)
        at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1322)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:131)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:113)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:93)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:90)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:157)
        at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:92)
        at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:107)
        at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:76)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:210)

Comment 45 Andreas Höhmann 2019-03-15 04:38:25 EDT

Created attachment 277876 [details]
Screenshot of my action which triggers the hanging

Comment 46 Andreas Höhmann 2019-03-15 04:44:28 EDT

And here my eclipse version information:

Eclipse IDE for Enterprise Java Developers.
Version: 2018-12 (4.10.0)
Build id: 20181214-0600

The project is maven project
aspectj is used

$ mvn -version
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
Maven home: D:\Dev\ApacheMaven\current-maven
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: D:\Dev\java\jdk8x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Comment 47 Stephan Herrmann 2019-09-15 07:44:51 EDT

*** Bug 467295 has been marked as a duplicate of this bug. ***

Comment 48 Eclipse Genie 2023-06-12 16:02:48 EDT

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.

If you have further information on the current state of the bug, please add it. 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.