Community
Participate
Working Groups
Build Identifier: I20100608-0911 I'm trying to do a debug session with a "suspend vm" breakpoint. However Eclipse keeps on going to a deadlock. Here are the stack traces of the threads in deadlock: Name: Worker-9 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@185e093f owned by: Worker-3 Total blocked: 701 Total waited: 756 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.getBreakpoints(JDIThread.java:371) org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getThreadText(JDIModelPresentation.java:308) org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getText(JDIModelPresentation.java:244) 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.getLabel(ElementLabelProvider.java:312) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:215) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:160) org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74) org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Name: Worker-3 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@2237ed25 owned by: Worker-4 Total blocked: 149 Total waited: 258 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.resumedByVM(JDIThread.java:1623) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.resumeThreads(JDIDebugTarget.java:1308) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.cancelSuspendByBreakpoint(JDIDebugTarget.java:1347) org.eclipse.jdt.internal.debug.core.model.JDIThread.completeBreakpointHandling(JDIThread.java:1171) - locked org.eclipse.jdt.internal.debug.core.model.JDIThread@185e093f 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:54) Name: Worker-4 State: BLOCKED on org.eclipse.jdt.internal.debug.core.model.JDIThread@185e093f owned by: Worker-3 Total blocked: 160 Total waited: 276 Stack trace: org.eclipse.jdt.internal.debug.core.model.JDIThread.resumedByVM(JDIThread.java:1623) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.resumeThreads(JDIDebugTarget.java:1308) org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.cancelSuspendByBreakpoint(JDIDebugTarget.java:1347) org.eclipse.jdt.internal.debug.core.model.JDIThread.completeBreakpointHandling(JDIThread.java:1171) - locked org.eclipse.jdt.internal.debug.core.model.JDIThread@2237ed25 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:54) I'm going to attach a full ThreadDump Reproducible: Always Steps to Reproduce: 1. debug a JUnit4 test case, setting up a breakpoint that suspends the VM
Created attachment 179008 [details] Full thread dump (from jVisualVM)
Do you recall if you had 2 breakpoints configured to suspend the VM, perhaps with conditions?
I'm almost sure I had just one with "suspend VM" AND a condition. The other breakpoints were with "suspend thread", with or without conditions.
Today I got the same Problem with 3.8.2 and slowing this deadlocks driving me crazy. I have multiple breakpoints, some are conditional, all are configured to suspend the vm. After the vm was stopped, I pressed resume and ended up in a state, where some of the threads where suspended and others resumed. If I press the resume button again, this will result in a deadlock. Between JDTThread.resumedByVM and JDTThread.suspendedByVM. This brings me to next bad thing, the whole workspace has to be rebuilt after the crash and all breakpoints created since the last proper shutdown are lost.
*** Bug 401421 has been marked as a duplicate of this bug. ***
I was debugging a similar problem, where Thread#run would not be called after a thread.start, which might lead to a deadlock if you do a thread.join after calling the start. I can reproduce with my machine that a thread is not started when previously a "suspend vm" breakpoint was hit. I very seriously suspect that this VM bug is the cause for my problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6526033 Maybe this is a cause also for this bug here?
Trying to create low level object locks to avoid synchronized method locks to minimize racing condition.
I am not able to reproduce this with one break point having Suspend VM condition. It reproduced easily with 2 breakpoints having Suspend VM conditions with Junits. If someone can provide an example to reproduce deadlock with one breakpoint having Suspend VM condition, it will help.
I tried creating a couple of ( 4 actually) Reentrant locks, removed the Synchronized tag from the methods and used the localized locks. I observe that it helps in some scenarios but not all the time, some threads start up but some are still in suspended state. It makes me think that it might be related to VM bug as mentioned in Comment#6. On the other hand I found a workaround to make it work and avoid the deadlock. After the breakpoint is hit, if we press the Resume button when the particular thread is selected, we have a chance of getting into deadlock. But if we select the main thread like org.eclipse.equinox.launcher.Main and then select Resume, there is no deadlock. Has anyone tried this workaround ?
Resuming from main thread works fine with Oracle and IBM both the JREs.
(In reply to Sarika Sinha from comment #10) > Resuming from main thread works fine with Oracle and IBM both the JREs. Could be related to the fix for bug 372030, where we added support for resuming threads individually.
Created attachment 242215 [details] JDI Thread resume() method to resume Debug Target as before !isSuspended() check was added before resuming Debug Target as part of Bug 37203. Removing this check I was able to run through 2 or more breakpoints with Suspend VM option. I was not able to reproduce Deadlock (with and without the patch ) with a single breakpoint having suspend VM condition.
Created attachment 242218 [details] JDI Thread resume() method to resume Debug Target as before Copyright added
(In reply to Sarika Sinha from comment #12) > Created attachment 242215 [details] [diff] > JDI Thread resume() method to resume Debug Target as before > > !isSuspended() check was added before resuming Debug Target as part of Bug > 37203. Removing this check I was able to run through 2 or more breakpoints > with Suspend VM option. And is bug 372030 still fixed with this change?
(In reply to Dani Megert from comment #14) > And is bug 372030 still fixed with this change? I am able to resume individual threads after applying the patch as well.
(In reply to Sarika Sinha from comment #15) > (In reply to Dani Megert from comment #14) > > > And is bug 372030 still fixed with this change? > > > I am able to resume individual threads after applying the patch as well. Bug 372030 was about resuming an individual thread after the whole VM was suspended. E.g. run bug 372030 comment 4, suspend the whole VM ("xy.Try at *"), and then try to resume thread "Try-0". This works without your patch, but doesn't work any more with it. What are the steps for reproducing the problem you're trying to fix?
(In reply to Markus Keller from comment #16) > (In reply to Sarika Sinha from comment #15) > > (In reply to Dani Megert from comment #14) > > > > > And is bug 372030 still fixed with this change? > > > > > > I am able to resume individual threads after applying the patch as well. > > Bug 372030 was about resuming an individual thread after the whole VM was > suspended. E.g. run bug 372030 comment 4, suspend the whole VM ("xy.Try at > *"), and then try to resume thread "Try-0". This works without your patch, > but doesn't work any more with it. > > What are the steps for reproducing the problem you're trying to fix? I tried the bug 372030 comment 4 code, and I was able to resume thread "Try-0" after the patch as well. Also before the patch it never moves to Try-1, Try2 and Try-3 even after we resume but with patch it does. What we are trying to fix is a case when we have more than 1 breakpoint with suspend VM condition being hit.
Not working on this.
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.
I think this is worth a new look, it has been reproduced, there's a pending review request and a proposed patch (which seems to work, not clear whether or not it breaks something else).
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.
