Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 418473 - NullPointerException when starting unit test
Summary: NullPointerException when starting unit test
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 4.3   Edit
Hardware: PC Mac OS X
: P3 critical (vote)
Target Milestone: 4.5 M2   Edit
Assignee: Michael Rennie CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-02 04:44 EDT by Martijn Dashorst CLA
Modified: 2014-09-18 07:49 EDT (History)
3 users (show)

See Also:
sarika.sinha: review+

Attachments
fix (33.27 KB, patch)
2014-08-26 14:45 EDT, Michael Rennie CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martijn Dashorst CLA 2013-10-02 04:44:15 EDT 
The following NPE ensures I don't get any work done.

java.lang.NullPointerException
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.getEnclosingReferenceTypeName(JavaBreakpoint.java:242)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.createRequests(JavaBreakpoint.java:595)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.addToTarget(JavaBreakpoint.java:584)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.addToTarget(JavaLineBreakpoint.java:172)
	at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.breakpointAdded(JDIDebugTarget.java:1287)
	at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.initializeBreakpoints(JDIDebugTarget.java:522)
	at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.initialize(JDIDebugTarget.java:448)
	at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.<init>(JDIDebugTarget.java:315)
	at org.eclipse.jdt.debug.core.JDIDebugModel$1.run(JDIDebugModel.java:183)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2345)
	at org.eclipse.jdt.debug.core.JDIDebugModel.newDebugTarget(JDIDebugModel.java:187)
	at org.eclipse.jdt.internal.launching.StandardVMDebugger.createDebugTarget(StandardVMDebugger.java:471)
	at org.eclipse.jdt.internal.launching.StandardVMDebugger.run(StandardVMDebugger.java:347)
	at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.launch(JUnitLaunchConfigurationDelegate.java:174)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:858)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:707)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1018)
	at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1222)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Comment 1 Martijn Dashorst CLA 2013-10-02 04:55:37 EDT 
The unit test that shows this bug:


package eclipsetest;

import org.junit.Assert;
import org.junit.Test;

public class UnitTest {
    public abstract static class FooProvider {
        public abstract FooInterface provide();
    }

    public interface FooInterface {
    }

    public abstract static class FooSimpleExtensionPoint implements
            FooInterface {
        public abstract boolean include();
    }

    @Test
    public void foo() {
        class BarProvider extends FooProvider {
            @Override
            public FooInterface provide() {
                FooInterface iface = new FooSimpleExtensionPoint() {
                    @Override
                    public boolean include() {
                        System.out.println("Breakpoint fails here");
                        return false;
                    }
                };
                return iface;
            }
        }
        FooProvider p = new BarProvider();
        Assert.assertNotNull(p);
    }
}
Comment 2 Michael Rennie CLA 2013-10-02 10:50:32 EDT 
looks like you have a breakpoint with no backing type name (which is allowed in theory), but we do not check for null-ness in the breakpoint call-back
Comment 3 Rob Stryker CLA 2014-08-26 09:44:18 EDT 
This bug is really troublesome. Once a breakpoint is invalid, we can't remove it, since going to the breakpoints tab fails to show any breakpoints. A restart of the workbench won't help, since the breakpoint is persisted. I don't know where to go to clear the breakpoints manually. 

Essentially, my entire workspace is broken and I cannot fix it without starting a new one.
Comment 4 Rob Stryker CLA 2014-08-26 09:45:00 EDT 
Marking as critical since my workspace is now broken.
Comment 5 Rob Stryker CLA 2014-08-26 10:00:34 EDT 
Workaround:  In breakpoint view, right-click, and select "Remove All". 

This workaround is not intuitive, though, since most users will see the empty view and assume there already are 0 breakpoints declared.
Comment 6 Michael Rennie CLA 2014-08-26 14:45:17 EDT 
Created attachment 246383 [details]
fix

This patch makes sure we check for nullness before using the typename from a breakpoint and adds unit tests for the model presentation + launching with null-typed breakpoints.
Comment 8 Sarika Sinha CLA 2014-09-18 07:49:16 EDT 
Verified with the tests using 
Eclipse SDK

Version: Mars (4.5)
Build id: I20140916-2000