Bug 5113 - NPE in Java Model Presentation
Summary: NPE in Java Model Presentation
Status: RESOLVED DUPLICATE of bug 5871
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: Jared Burns CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-19 12:14 EDT by Darin Wright CLA
Modified: 2001-11-14 11:03 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Wright CLA 2001-10-19 12:14:54 EDT
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.
Comment 1 Darin Wright CLA 2001-10-19 15:47:53 EDT
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).
Comment 2 Darin Wright CLA 2001-10-19 15:48:06 EDT
Please verify.
Comment 3 Jared Burns CLA 2001-11-08 14:50:15 EST
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.
Comment 4 Darin Wright CLA 2001-11-08 15:57:47 EST
Why is the exception being thrown - are we updating/accessing a debug model 
element after the VM has exited?
Comment 5 Darin Swanson CLA 2001-11-13 10:02:21 EST
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.
Comment 6 Darin Wright CLA 2001-11-14 09:10:53 EST
Assigning to Jared, as he has been enhancing the disconnection support. Unsure 
if this is still a problem.
Comment 7 Jared Burns CLA 2001-11-14 11:03:24 EST

*** This bug has been marked as a duplicate of 5871 ***