Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317790

Summary:	Deadlock in JDIThread after hotcode replacement
Product:	[Eclipse Project] JDT	Reporter:	Heiko Böttger <heiko.boettger>
Component:	Debug	Assignee:	JDT-Debug-Inbox <jdt-debug-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	darin.eclipse
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:	stalebug

Description Heiko Böttger

2010-06-24 05:21:20 EDT

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.

Comment 1 Darin Wright

2010-06-24 09:41:39 EDT

"Build Identifier: 20100218-1602" looks like an old 3.6 I-build. Do you know if this happens on the final 3.6?

Comment 2 Darin Wright

2010-06-24 09:56:33 EDT

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?

Comment 3 Heiko Böttger

2010-06-24 14:52:53 EDT

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?

Comment 4 Darin Wright

2010-06-24 15:05:50 EDT

(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)

Comment 5 Eclipse Genie

2020-02-04 07:40:21 EST

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.