Community
Participate
Working Groups
In the method SocketAttachConnector.connect(....) a virtual machine is created by VirtualMachine vm = connector.attach(map); This obviously connects to the remote debug process. If the subsequent call to debugTarget= JDIDebugModel.newDebugTarget(launch, vm, vmLabel, null, allowTerminate, true); fails (eg. by a time-out), the connection to the remote VM is not terminated leaving the debug port of the remote VM blocked. Since there is no means to get the associated VirtualMachine object I can cannot do this in my LaunchConfigurationDelegate. Either there should be a method getVm(): VirtualMachine in the IVMConnector interface or you catch all Throwables and release the connection on catching the error (eventually in method abort()). Cheers Richard
*** Bug 66332 has been marked as a duplicate of this bug. ***
*** Bug 66334 has been marked as a duplicate of this bug. ***
Do you have an example of how/where the contsructor of the target fails? The constuctor iteself does not throw an exception, and all creation/init of the target catches/handles exceptions (from what I see).
Deferred - but still want example of how this fails/or patch that demonstrates the fix you are looking for.
Created attachment 12005 [details] Proposed SocketAttachingConnector changes
The stack trace looks like this (from e-mail). We are not catching a timeout exception in VirtualMachine.allClasses(), which is used in the pattern breakpoint installation code. java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:283) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run (ProgressMonitorDialog.java:357) at org.eclipse.debug.ui.DebugUITools.launch(DebugUITools.java:494) at org.eclipse.debug.ui.actions.AbstractLaunchToolbarAction.run (AbstractLaunchToolbarAction.java:69) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251) at org.eclipse.ui.internal.WWinPluginAction.runWithEvent (WWinPluginAction.java:207) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:456) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:403) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:397) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:72) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:81) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2022) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1729) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1402) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385) at com.tssap.util.startup.WBLauncher.run(WBLauncher.java:79) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:858) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) 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 com.sap.ide.eclipse.startup.Main.basicRun(Main.java:291) at com.sap.ide.eclipse.startup.Main.run(Main.java:791) at com.sap.ide.eclipse.startup.Main.main(Main.java:604) Caused by: org.eclipse.jdi.TimeoutException at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply (PacketReceiveManager.java:149) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply (PacketReceiveManager.java:158) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:173) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:229) at org.eclipse.jdi.internal.VirtualMachineImpl.allClasses (VirtualMachineImpl.java:327) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaPatternBreakpoint.addToTarg et(JavaPatternBreakpoint.java:96) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.breakpointAdded (JDIDebugTarget.java:1007) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.initializeBreakpoints (JDIDebugTarget.java:413) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.initialize (JDIDebugTarget.java:365) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.<init> (JDIDebugTarget.java:246) at org.eclipse.jdt.debug.core.JDIDebugModel$1.run(JDIDebugModel.java:145) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1595) at org.eclipse.jdt.debug.core.JDIDebugModel.newDebugTarget (JDIDebugModel.java:149) at org.eclipse.jdt.debug.core.JDIDebugModel.newDebugTarget (JDIDebugModel.java:109) at org.eclipse.jdt.internal.launching.SocketAttachConnector.connect (SocketAttachConnector.java:133) at com.sap.ide.eclipse.rdebug.RDebugLaunchConfigurationDelegate.launch (RDebugLaunchConfigurationDelegate.java:119) at org.eclipse.debug.internal.core.LaunchConfiguration.launch (LaunchConfiguration.java:156) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch (DebugUIPlugin.java:676) at org.eclipse.debug.ui.DebugUITools.buildAndLaunch(DebugUITools.java:538) at org.eclipse.debug.ui.DebugUITools$2.run(DebugUITools.java:487) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:101)
Propose to catch timeout exception on breakpoint installation code.
I subclassed org.eclipse.jdt.internal.launching.SocketAttachConnector catching the RuntimeException as I described. This works fine for me so far leaving only a problem when subsequently adding/removing breakpoints. Since JDIDebugTarget is registered as breakpointlistener prior to the Exception the instance, although not being instantiated correctly, seems to remain registered as listener. It is therefore called when a new breakpoint is added/removed causing a VMDisconnectedException (if I terminate the VM by vm.dispose). Therefore I think it might be necessary to deregister the (failed) JDIDebugTarget if the constructor fails. Regards Richard
Created attachment 12216 [details] Demo for class registered a listener where constructor fails Demonstrates that a class can be registered as a listener in its constructor although the constructor fails after the registration. Calls from the registree are possible as well access to class members, although the class does not exist in a logical manner.
Created attachment 12257 [details] patch This patch catches any JDI/communication exceptions and wraps them in a CoreException, which is handled. Any unexpected exceptions are re-thrown to avoid hiding programming errors.
Luc, please approve the patch.
Ping Philippe for RC3 approval.
(Philippe, do you approve for RC3?)
Darin, we should apply the same change on JavaStratumLineBreakpoint, no ?
(Yes)
The patch solve the problem.
+1 to fix for RC3.
Changes in JavaStratumBreakpoint, JavaPatternBreakpoint, and addition of NLS message in JDIDebugBreakpointMessages.
Please verify, Kevin.
oops.
