Community
Participate
Working Groups
Build Identifier: 20100218-1602 Name: Worker-489 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@11c3173 owned by: Worker-487 Total blocked: 90'882 Total waited: 92'788 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.isOutOfSynch(JDIThread.java:1242) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.isOutOfSynch(JDIDebugTarget.java:797) org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getText(JDIModelPresentation.java:252) org.eclipse.debug.internal.ui.LazyModelPresentation.getText(LazyModelPresentation.java:185) org.eclipse.debug.internal.ui.DelegatingModelPresentation.getText(DelegatingModelPresentation.java:158) org.eclipse.debug.internal.ui.model.elements.DebugElementLabelProvider.getLabel(DebugElementLabelProvider.java:35) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:212) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:157) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:71) org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Name: Worker-487 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@55e599 owned by: Worker-475 Total blocked: 104'003 Total waited: 106'400 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.resumedByVM(JDIThread.java:1618) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.resumeThreads(JDIDebugTarget.java:1294) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.cancelSuspendByBreakpoint(JDIDebugTarget.java:1333) org.eclipse.jdt.internal.debug.core.model.JDIThread.completeBreakpointHandling(JDIThread.java:1166) - locked org.eclipse.jdt.internal.debug.core.model.JDIThread@11c3173 org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.eventSetComplete(JavaBreakpoint.java:311) org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:204) org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:104) org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:250) org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Name: Worker-475 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@11c3173 owned by: Worker-487 Total blocked: 103'730 Total waited: 106'578 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.resumedByVM(JDIThread.java:1618) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.resumeThreads(JDIDebugTarget.java:1294) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.cancelSuspendByBreakpoint(JDIDebugTarget.java:1333) org.eclipse.jdt.internal.debug.core.model.JDIThread.completeBreakpointHandling(JDIThread.java:1166) - locked org.eclipse.jdt.internal.debug.core.model.JDIThread@55e599 org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.eventSetComplete(JavaBreakpoint.java:311) org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:204) org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:104) org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:250) org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Reproducible: Always Steps to Reproduce: Don't know how to reproduce this exactly, but it happens after hotcode replacement.
"Build Identifier: 20100218-1602" looks like an old 3.6 I-build. Do you know if this happens on the final 3.6?
Do you know what sort of breakpoints you had set at the time this happenned? Do you have conditional breakpoints configured to suspend the VM?
My eclipse is a 3.5.2 with the latest updates installed. I think the deadlock occured when I used a conditional breakpoint catching all uncaught and caught Throwable's. I haven´t used helios until now, so I cannot say, if it's already fixed there. Our company will switch to helios in two month, I will add a comment if I see it again. Do you think this is already fixed, on the helio release?
(In reply to comment #3) > Do you think this is already fixed, on the helio release? Not sure... we have not addressed this deadlock specifically. The stack traces provided make the problem look pretty intricate. It looks like there are two threads handling breakpoints that suspend the VM... and I'm not sure how that happens (since once the first breakpoint suspends the VM, another thread should not be able to hit a breakpoint... unless it's doing a user initiated evaluation and hitting a breakpoint...). To be sure, steps to reproduce would be helpful (but I know that is difficult)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
