Community
Participate
Working Groups
I was opening a type via the "open type" dialog and the IDE became unresponsive. I did 3 stack dumps, and the all looked like this: "VM Periodic Task Thread" prio=10 tid=0x0023e570 nid=0x3b8 waiting on condition "Suspend Checker Thread" prio=10 tid=0x00920388 nid=0x3c0 runnable Full thread dump Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode): "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x18847a88 n id=0x674 runnable [1bc4f000..1bc4fd94] at java.util.zip.ZipFile.getNextEntry(Native Method) at java.util.zip.ZipFile.access$400(ZipFile.java:26) at java.util.zip.ZipFile$2.nextElement(ZipFile.java:313) - locked <0x1009ff08> (a java.util.zip.ZipFile) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren( JarPackageFragmentRoot.java:84) at org.eclipse.jdt.internal.core.PackageFragmentRoot.buildStructure(Pack ageFragmentRoot.java:172) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:20 0) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement. java:487) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement. java:278) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement. java:264) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.jav a:219) at org.eclipse.jdt.internal.core.NameLookup.getPackageFragmentsInRoots(N ameLookup.java:396) at org.eclipse.jdt.internal.core.NameLookup.configureFromProject(NameLoo kup.java:138) at org.eclipse.jdt.internal.core.NameLookup.<init>(NameLookup.java:100) at org.eclipse.jdt.internal.core.JavaProject.getNameLookup(JavaProject.j ava:1342) - locked <0x112d8338> (a org.eclipse.jdt.internal.core.JavaProjectElemen tInfo) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUn it.java:1025) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUn it.java:1007) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconci le(JavaReconcilingStrategy.java:72) - locked <0x1350d510> (a org.eclipse.jdt.internal.core.CompilationUnit) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.initial Reconcile(JavaReconcilingStrategy.java:126) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoR econciler.java:104) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread .run(AbstractReconciler.java:155) "Worker-19" prio=7 tid=0x187573a8 nid=0x6e0 in Object.wait() [1b8ef000..1b8efd94 ] at java.lang.Object.wait(Native Method) - waiting on <0x10517360> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:109) - locked <0x10517360> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:13 5) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Java indexing" daemon prio=4 tid=0x009c5670 nid=0x6a0 in Object.wait() [1907f00 0..1907fd94] at java.lang.Object.wait(Native Method) - waiting on <0x10a99b10> (a org.eclipse.jdt.internal.core.search.indexi ng.IndexManager) at java.lang.Object.wait(Object.java:429) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:358) - locked <0x10a99b10> (a org.eclipse.jdt.internal.core.search.indexing.I ndexManager) at java.lang.Thread.run(Thread.java:534) "Signal Dispatcher" daemon prio=10 tid=0x00920cd8 nid=0x4d8 waiting on condition [0..0] "Finalizer" daemon prio=9 tid=0x0091df00 nid=0x488 in Object.wait() [1816f000..1 816fd94] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x104fac88> (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=0x0091ca78 nid=0x538 in Object.wait() [18 12f000..1812fd94] at java.lang.Object.wait(Native Method) - waiting on <0x104facf0> (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 <0x104facf0> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x00235380 nid=0x6a8 waiting for monitor entry [6f000..6fc3c] at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$MouseClickListener. getCurrentTextRegion(JavaEditor.java:528) - waiting to lock <0x1350d510> (a org.eclipse.jdt.internal.core.Compilat ionUnit) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$MouseClickListener. mouseMove(JavaEditor.java:751) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java: 140) 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:2172) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1862) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2064) at org.eclipse.ui.internal.Workbench.run(Workbench.java:2047) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoa der.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(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:298) at org.eclipse.core.launcher.Main.run(Main.java:764) at org.eclipse.core.launcher.Main.main(Main.java:598) "VM Thread" prio=5 tid=0x0095d748 nid=0x3a0 runnable "VM Periodic Task Thread" prio=10 tid=0x0023e570 nid=0x3b8 waiting on condition "Suspend Checker Thread" prio=10 tid=0x00920388 nid=0x3c0 runnable
Asking Text for comments. This lock occurs in org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$MouseClickListener. getCurrentTextRegion
It's not a deadlock: the mouse click listener wants to acquire a lock which is currently hold by the reconciler thread. This thread is running - currently in Jdt Core code opening/reading a zip file which apparently seems to take very long. Darin, if possible can you give a bit more context: - when/how it happened, - what kind of type you opened - how you opened the type Moving to Jdt Core for comments.
I was simply re-starting a workspace that had a type hierarchy view open. I had to kill the VM several times (it just never seemed to get anywhere - the thread dump was always the same). I do not know what type hierarhcy was open.
This means the summary is wrong, correct? There was also at least one Java editor open, correct?
True - it was a hang while re-starting the workspace. There could have been multiple editors open.
Darin, can you still reproduce it ? If so, I would be curious to see if this would be still occurring on a different VM. The zipfile reading shouldn't hang.
The problem went away. Initially, the problem occurred when I moved from the I20030925 build to the I20030930 build, on my development workspace. So, I reverted to the "25" build, and everything worked. Later, I moved "forward" to the "30" build, and the problem never occurred again (I assume I had a different set of open views/editors when I moved to the new build).
Darin, I cannot reproduce this bug using VM Sun 1.4.1 following your scenario. We suspect here a possible problem in VM which can perform concurrent access to a zip file (rt.jar for example) outside Eclipse. It could be also a problem of VM version as Philippe told me that you were using a VM 1.4.2 when this issue occured. So, I close this bug as it seems not to be a jdt-core problem. Frederic
*** Bug 37259 has been marked as a duplicate of this bug. ***
