Community
Participate
Working Groups
The test suite is showing transient failures caused by transport errors: Test case: testSimpleStepFilter Never received event: Suspend Process exit value: 0 Console output follows: StepFilterTwo.test()Transport error, error code = -1 StepFilterThree.go() Test case: testSkipPatternBreakpoint Never received event: Suspend Process exit value: 0 Console output follows: Initializer Constructor Threading Constructor If Else for for for while while while block dowhile dowhile dowhile dowhile dowhile catch block finally after catch try finally after try switch switch default synchronized inner instance inner instance Transport error, error code = -1 Test case: testUnanimousSuspendVote Never received event: Suspend Process exit value: 0 Console output follows: Initializer Constructor Threading Constructor If Else for for for while while while block dowhile dowhile dowhile dowhile dowhile catch block finally after catch try finally after try switch switch default synchronized inner instance inner instance Transport error, error code = -1 Test case: testDeferredExpression Never received event: Suspend Process exit value: 0 Console output follows: Transport error, error code = -1
Appears to be the new model proxy initialization code that is triggering the disconnect. (I dumped a stack trace by throwing an illegal arg exception when a disconnect occurrs. The illegal arg is just a hack here). Not sure why the "installed" code causes this problem: java.lang.IllegalArgumentException: disconnected at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.disconnected(JDIDebugTarget.java:1305) at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.disconnected(JDIDebugElement.java:311) at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.throwDebugException(JDIDebugElement.java:201) at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.requestFailed(JDIDebugElement.java:158) at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.targetRequestFailed(JDIDebugElement.java:143) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames(JDIThread.java:511) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:419) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:483) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getTopStackFrame(JDIThread.java:937) at org.eclipse.debug.internal.ui.viewers.update.DebugTargetProxy.installed(DebugTargetProxy.java:77) at org.eclipse.debug.internal.ui.viewers.AsynchronousViewer.installModelProxy(AsynchronousViewer.java:434) at org.eclipse.debug.internal.ui.viewers.AsynchronousViewer.map(AsynchronousViewer.java:392) at org.eclipse.debug.internal.ui.viewers.AsynchronousTreeViewer.map(AsynchronousTreeViewer.java:324) at org.eclipse.debug.internal.ui.viewers.AsynchronousTreeViewer$4.run(AsynchronousTreeViewer.java:507) at org.eclipse.debug.internal.ui.viewers.AsynchronousViewer.preservingSelection(AsynchronousViewer.java:902) at org.eclipse.debug.internal.ui.viewers.AsynchronousTreeViewer.setChildren(AsynchronousTreeViewer.java:472) at org.eclipse.debug.internal.ui.viewers.ChildrenRequestMonitor.performUpdate(ChildrenRequestMonitor.java:71) at org.eclipse.debug.internal.ui.viewers.AsynchronousRequestMonitor$1.runInUIThread(AsynchronousRequestMonitor.java:170) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:93) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3218) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2864) at org.eclipse.jdt.debug.tests.DebugSuite.run(DebugSuite.java:67) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:57) at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:105) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3218) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2864) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1762) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1726) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:397) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:106) at org.eclipse.pde.internal.junit.runtime.UITestApplication.run(UITestApplication.java:45) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:338) at org.eclipse.core.launcher.Main.basicRun(Main.java:282) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
Appears related to inconsistent thread state in the model and target. When a target is created, class prepare requests are set for each deferred breakpoint. These requests are handled by the breakpoint class without tellingt the thread/target that the thread has actually suspended (i.e. never effects model state). If a thread's state is being initialized as a class prepare is hit, the thread can init its state to suspended even though this is just a transient state. This appears to cause the disconnect (asking for frames when the model thinks its suspended, when its not... although I think that is really a VM bug). Fixed in JDIThread.initialize()/getBreakpoints(). Thread state is set to "running" when the model doesn't know about breakpoints, even if the target thinks its suspended. This is safe, as the thread state will be set to suspeneded in the case that a breakpoint is really hit.
Please verify, Kevin.
verified
