Community
Participate
Working Groups
I had an active VM after doing an evaluation in a snippet editor. Hovered over part of the snippet Found this in the Console. Was also able to get the dump in the active editor. Not consistently reproduceable. java.lang.NullPointerException at org.eclipse.jdi.internal.ObjectReferenceImpl.isCollected (ObjectReferenceImpl.java:391) at org.eclipse.jdt.internal.debug.core.model.JDIValue.isAllocated (JDIValue.java:278) at org.eclipse.jdt.internal.debug.core.model.JDIValue.getVariables0 (JDIValue.java:188) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.findVariable (JDIStackFrame.java:574) at org.eclipse.jdt.internal.debug.core.model.JDIThread.findVariable (JDIThread.java:1400) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.findVariable (JDIDebugTarget.java:1364) at org.eclipse.jdt.internal.debug.ui.JavaDebugHover.getHoverInfo (JavaDebugHover.java:91) at org.eclipse.jdt.internal.ui.text.java.hover.JavaTextHover.getHoverInfo (JavaTextHover.java:304) at org.eclipse.jface.text.TextViewerHoverManager$2.run (TextViewerHoverManager.java:88)
MirrorImpl.requestVM(...) can return a null reply, though the JavaDoc does not say this. We've seen this issue before and it was flagged for investigation, but I can't find the original report. Ultimately, the null is coming from PacketReceiveManger.getReply(JdwpCommandPacket commandPacket).
The original stack trace says the exception occurred on line 391. The line numbers of ObjectReferenceImpl have since changed. The line where the NPE occurred is the line in ObjectReferenceImpl.isCollected() which reads: switch (replyPacket.errorCode()) {
Investigate how to handle VM disconnects/communitcation errors. Currently we are vulnerable to NPEs when a "reply" fails. A general proposal is required before proceeding.
Additional problem reported by eharris: Do you have any idea what might cause the following exception? Unfortunately it is fairly difficult to reproduce - using WSAD, attach and detach from the same server 2 times, attach a third time and it fails. The problem occurs when my debug adapter is just created and is getting the list of currently existing threads from JDT. I am having trouble debugging as after this error my machine hangs so I just thought I would ask if you had any ideas. Thanks for your help. java.lang.NullPointerException org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:2119) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:98) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1506) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1294) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1177) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1160) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:775) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:432) at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:24) *** Stack trace of contained exception *** java.lang.NullPointerException at org.eclipse.jdi.internal.ThreadReferenceImpl.frames (ThreadReferenceImpl.java:176) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames (ThreadReferenceImpl.java:159) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames (JDIThread.java:482) at org.eclipse.jdt.internal.debug.core.model.JDIThread.createAllStackFrames (JDIThread.java:459) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames (JDIThread.java:351) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames (JDIThread.java:431) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getStackFrames (JDIThread.java:335) at com.ibm.debug.wsa.internal.core.WSAJavaThread.computeStackFrames (WSAJavaThread.java:754) at com.ibm.debug.wsa.internal.core.WSAThread.hasStackFrames(WSAThread.java:159) at org.eclipse.debug.internal.ui.views.launch.LaunchViewContentProvider.hasChildren (LaunchViewContentProvider.java:88) at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable (AbstractTreeViewer.java:926) at org.eclipse.jface.viewers.AbstractTreeViewer.updatePlus (AbstractTreeViewer.java:1269) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem (AbstractTreeViewer.java:259) at org.eclipse.jface.viewers.AbstractTreeViewer.add(AbstractTreeViewer.java:130) at org.eclipse.jface.viewers.AbstractTreeViewer.add(AbstractTreeViewer.java:163) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler.insert (AbstractDebugEventHandler.java:74) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleDebugE vents(LaunchViewEventHandler.java:81) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler$1.run (AbstractDebugEventHandler.java:49) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:31) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:95) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1506) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1294) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1177) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1160) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:775) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:432) at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:24)
Here are more detailed instructions to reproduce. This requires WSAD. It uses the remote attach server which requires WAS to be installed as well. However you can start the test environment server on the example, detach from it, note the jvm port (in the debug target label) and create a remote attach server specifying this port in the server configuration. Unfortunately I have not been able to reproduce this consistently in a simpler situation. This scenario, however, does fail consistently. I am willing to help someone to reproduce this if this will help. Create the JSPandServletExample web project (this is one of the samples shipped with WSAD). From the Web perspective, select JSPandServletExample project, right click, Debug on Server, and select the Server Attach server that I have defined (attachsutton). After connecting to the server has completed, disconnect from the server. Now from the Debug Launcher history select the Server Attach launcher just used (attachsutton). After connecting to the server has completed, disconnect from the server. From the Web perspective, select JSPandServletExample project, right click, Debug on Server, and select the Server Attach server that I have defined (attachsutton). This is when the failure occurs.
Erin, do you disconnect from the server or terminate the server? When I disconnect I get errors when I attempt to reconnect. Also, could you describe how you set up the server attach server that you mention?
I am disconnecting from the server. Here are the steps: 1. create the JSPandServletExample 2. debug the JSPandServletExample using the v5.0 test environment 3. once the server is completely started (open for e-business), disconnect from the server, make sure to note the JVM port number from the debug target label 4. switch to the web perspective 5. select the server configuration view in the web perspective 6. right click in the view and select new -> server and server configuration 7. give the server a name (such as "v5.0 remote attach") and fill in the folder name (this can be anything, e.g. "Servers") 8. in the server type box expand "WebSphere version 5.0" and select "Remote Server Attach" 9. click "Next" twice so that you are on the page will all of the ports. 10. change the "JVM debug port" to the port number from step 3. 11. click "Finish" 12. you should now have a server and server configuration with the name you gave it 13. right click on your newly created server configuration 14. select add -> DefaultEAR (or whatever name you gave the ear file for the JSPandServletExample) 15. switch back to the j2ee navigator view 16. right click on the JSPandServletExample project and select "Debug on Server" 17. select your newly created server 18. this is the first attach, continue with the other two attaches as described in the previous append (substitute your new server for attachsutton) Let me know if you have any problems.
I forgot to mention, once you have created the remote attach server you can change the JVM port number if needed. In the server configuration view double click on your remote attach server configuration. This will bring it up in the editor from where you can change the JVM port. Also in step 14 where I said ear file I should have said ear project.
Created attachment 1848 [details] jsp (test2.jsp) to reproduce the problem
Here is a quicker way to reproduce the problem: 1. In WSAD create a new web project (File->New->Project, select Web). 2. Fill in a name for the project (e.g. Test2). 3. Click Finish. 4. Copy test2.jsp (attached to this bug) into the "Web Content" directory of the new Test2 project. 5. Refresh the Test2 project. 6. Right click on Test2 and select Debug on Server. 7. In the dialog, select a v5.0 Test Environment server. If one is not created the dialog will let you create one. 8. When the server has started it will automatically try to load a page in the browser, stop it and load http://localhost:9080/Test2/test2.jsp (if you called your project something other than Test2 change the URI to have your project name instead of Test2). 9. When the dialog comes up to ask if you want to step into the jsp select OK. 10. Step over twice until you hit line 29 of test2.jsp. If the debugger runs away the first time just reload the page in the browser and follow steps 9 and 10 again. This is a bug in the BSF debug engine where it does not stop the first time the page is loaded in the server. 11. Now run the thread. The page should come up in the browser. 12. Disconnect from the server jvm. 13. Create a Remote Java Application launch configuration using the jvm port number from the label of the debug target you just disconnected from. 14. Debug using this launch configuration. 15. Check the .log file, it should look like this: java.lang.NullPointerException at org.eclipse.jdi.internal.ThreadReferenceImpl.name(ThreadReferenceImpl.java:258) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getName(JDIThread.java:809) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getThreadText(JDIModelPre sentation.java:276) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getText(JDIModelPresentat ion.java:202) at org.eclipse.debug.internal.ui.LazyModelPresentation.getText(LazyModelPresentatio n.java:68) at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getText(DelegatingMode lPresentation.java:121) at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:82) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.jav a:354) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1136 ) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.j ava:258) at org.eclipse.jface.viewers.AbstractTreeViewer.add(AbstractTreeViewer.java:130) at org.eclipse.jface.viewers.AbstractTreeViewer.add(AbstractTreeViewer.java:163) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler.insert(AbstractDeb ugEventHandler.java:74) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleDebugE vents(LaunchViewEventHandler.java:81) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler$1.run(AbstractDebu gEventHandler.java:49) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java(Compiled Code)) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java(Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.jface.window.Window.runEventLoop(Window.java(Compiled Code)) at org.eclipse.jface.window.Window.open(Window.java:537) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog.doL astLaunchedConfig(LaunchConfigurationDialog.java:617) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog.ope n(LaunchConfigurationDialog.java:578) at org.eclipse.debug.internal.ui.actions.OpenLaunchConfigurationsAction.run(OpenLau nchConfigurationsAction.java:132) at org.eclipse.jface.action.Action.runWithEvent(Action.java:749) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionCont ributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(Actio nContributionItem.java(Compiled Code)) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(Actio nContributionItem.java(Compiled Code)) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(Actio nContributionItem.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java(Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java(Compiled Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1160) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:77 5) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:248) at org.eclipse.core.launcher.Main.run(Main.java:698) at org.eclipse.core.launcher.Main.main(Main.java:534)
Cannot reproduce. Which builds of WSAD and Eclipse are you using?
I am using the 20020814_0100-WB20-V50R WSAD build which is built with the eclipse 2.0 release.
Make sure that for the "Remote Server Attach" server configuration, the BSF debug port is set to 4444 (it should be by default).
Created attachment 1860 [details] Steps to reproduce the problem. Unzip and read Steps.txt.
Jared, Erin's attachment is a zip, would you please have a look?
I found a path in the code where null could be returned by the PacketReceiveManager#getReply(...). The case is where the target VM is in the process of disconnecting while we are waiting for a reply. Making a patch for testing - a VMDisconnectException shoud be thrown in this case.
I was able to reproduce Erin's problem reliably. Tried the SUN JDI client and found that it worked with no problems. I then discovered that our PacketReceiveManager was being "interrupted", but not by our code (which is the expected execution path when the VM disconnects). This caused the code to follow a path were it returned null, since the thread was interrupted, but the VM was not disconnected. Updated packet receive manager to handle interrupts, and continue receiving packets, waiting for not more than the JDI timeout period (or until VM is disconnected). Either the VM disconnects, or the request times out, but null is never returned. In this case, it appears the communication now proceeds successfully after the (unexpected) interrupt. Sending patch to Erin for testing. Should make available for 2.0.2. Released fix to HEAD.
*** Bug 19433 has been marked as a duplicate of this bug. ***
Released to 202 branch as well. Fixed.
Please verify, Luc.
The code of PacketRecieverManager#getCommand(int, long) is really close to the code of PacketRecieverManager#getReply(int, long), is there any possibility we get the same problem with this method ? btw, there is an error in PacketRecieverManager#getCommand(int, long), "waitForPacketAvailable(timeToWait);" should be "waitForPacketAvailable(remainingTime);"
Yes, I have noted the same bug in my code review (which we can clean up in 2.1), but it is not causing the problem for this error (in 2.0.1). The "getCommand" code is used to receive events from the VM, from the "EventQueue". In this case, it is API for the client to handle the InterruptedException - see com.sun.jdi.EventQueue.remove(). Thus, there is no effective change in the runtime behavior of the code.
