Community
Participate
Working Groups
Running the test suite, many "unable to execute runnable dialogs" appear. These are due to an NPE in the JavaModelPresentation: e= SWTException (id=48) backtrace= Object[10] (id=54) code= 46 detailMessage= "Failed to execute runnable" throwable= NullPointerException (id=59) backtrace= Object[30] (id=67) [0]= int[29] (id=68) [1]= Class (org.eclipse.jdt.internal.debug.ui.JDIModelPresentation) (id=69) [2]= Class (org.eclipse.jdt.internal.debug.ui.JDIModelPresentation) (id=69) [3]= Class (org.eclipse.jdt.internal.debug.ui.JDIModelPresentation) (id=69) [4]= Class (org.eclipse.debug.internal.ui.LazyModelPresentation) (id=70) [5]= Class (org.eclipse.debug.internal.ui.DelegatingModelPresentation) (id=71) [6]= Class (org.eclipse.jface.viewers.TreeViewer) (id=72) [7]= Class (org.eclipse.jface.viewers.AbstractTreeViewer) (id=73) [8]= Class (org.eclipse.jface.viewers.StructuredViewer) (id=74) [9]= Class (org.eclipse.jface.viewers.AbstractTreeViewer) (id=73) [10]= Class (org.eclipse.jface.viewers.AbstractTreeViewer) (id=73) [11]= Class (org.eclipse.jface.viewers.AbstractTreeViewer) (id=73) [12]= Class (org.eclipse.jface.viewers.AbstractTreeViewer) (id=73) [13]= Class (org.eclipse.jface.viewers.StructuredViewer$1) (id=75) [14]= Class (org.eclipse.jface.viewers.StructuredViewer) (id=74) [15]= Class (org.eclipse.jface.viewers.StructuredViewer) (id=74) [16]= Class (org.eclipse.debug.internal.ui.DebugView) (id=76) [17]= Class (org.eclipse.debug.internal.ui.LaunchesViewer) (id=77) [18]= Class (org.eclipse.debug.internal.ui.DebugContentProvider) (id=78) [19]= Class (org.eclipse.debug.internal.ui.DebugContentProvider) (id=78) [20]= Class (org.eclipse.debug.internal.ui.BasicContentProvider$1) (id=79) [21]= Class (org.eclipse.swt.widgets.RunnableLock) (id=80) [22]= Class (org.eclipse.swt.widgets.Synchronizer) (id=65) [23]= Class (org.eclipse.swt.widgets.Display) (id=66) [24]= Class (org.eclipse.swt.widgets.Display) (id=66) [25]= Class (org.eclipse.ui.internal.Workbench) (id=13) [26]= Class (org.eclipse.ui.internal.Workbench) (id=13) [27]= Class (org.eclipse.core.internal.boot.InternalBootLoader) (id=44) [28]= Class (org.eclipse.core.boot.BootLoader) (id=45) [29]= Class (SlimLauncher) (id=46) detailMessage= null JDIStackFrame is returning null in many cases (in this case from getReceivingTypeName), when the VM disconnects, and the retrieval is being performed. The methods are not documented to return null, and should actually just throw a DebugException.
Fixed. I changed the implementation of JDIDebugElement#targetRequestFailed to always throw an exception. We used to hide VMDisconnectedExceptions when the VM was terminating. However, there are only a handful of situations where we want to ignore VMDisconnect's, so those are now coded excplicitly. Anywhere else, a disconnect is an unexpected exception that should be propagated to the client. Running the test suite now produces no "Unable to excecute Runnable" dialogs. (re-assigning for verification).
Please verify.
I believe this the cause of a lot of recent trouble on Linux. We're throwing VMDisconnected exceptions quite a lot now. It's a timing issue, so the bug cannot be reproduced with 100% accuracy, however it's not hard to make it happen. It might take a few tries to see the problem but: 1. Debug a program to a breakpoint. 2. Resume it. 3. We throw a VMDisconnectedException which propogates to the user.
Why is the exception being thrown - are we updating/accessing a debug model element after the VM has exited?
The VMDisconnected exception is thrown as we send a "resume" command to the VM. It then happily finishes execution BEFORE we have had a chance in the JDI packet receive manager to get the reply packet for the resume command. Attempting to get the replay packet is what gets the IOException that is thrown as a VMDisconnected. Jared started looking into better ways of handling these cases.
Assigning to Jared, as he has been enhancing the disconnection support. Unsure if this is still a problem.
*** This bug has been marked as a duplicate of 5871 ***