This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE Dev (Build 201005290001) VM: Java HotSpot(TM) Client VM, 16.3-b01, Java(TM) SE Runtime Environment, 1.6.0_20-b02 OS: Windows Vista User Comments: javydreamercsw: Trying to run a test file after a project clean. (shift+F6 while on the file) Stacktrace: java.lang.NullPointerException: The project parameter cannot be null at org.openide.util.Parameters.notNull(Parameters.java:89) at org.netbeans.modules.gsf.testrunner.api.TestSession.<init>(TestSession.java:134) at org.netbeans.modules.junit.output.JUnitTestSession.<init>(JUnitTestSession.java:75) at org.netbeans.modules.junit.output.JUnitOutputReader.<init>(JUnitOutputReader.java:162) at org.netbeans.modules.junit.output.JUnitAntLogger.getOutputReader(JUnitAntLogger.java:397) at org.netbeans.modules.junit.output.JUnitAntLogger.buildFinished(JUnitAntLogger.java:352)
Created attachment 99685 [details] stacktrace
Created attachment 100027 [details] stacktrace
An assert statement is added to have more info about this bug: http://hg.netbeans.org/main/rev/bf6b880944b9
I recently encountered: java.lang.AssertionError: See bug 187004: project must not be null for projectDir="/tmp" at org.netbeans.modules.junit.output.JUnitAntLogger.getOutputReader(JUnitAntLogger.java:398) at org.netbeans.modules.junit.output.JUnitAntLogger.taskStarted(JUnitAntLogger.java:328) I don't know how to reproduce. Perhaps /tmp/pom.xml existed at some point and was later deleted. Anyway the code in junit should be more robust.
Created attachment 106268 [details] stacktrace I'm adding the stacktrace here, as the exception reporter in the current dev-builds does not seem to work.
This bug already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=170317
Created attachment 107793 [details] stacktrace
*** Bug 197606 has been marked as a duplicate of this bug. ***
Reproducibly prevents "Profile Test for File" from working on TestIntInt2ObjHash.java from https://jmol.svn.sourceforge.net/svnroot/jmol/trunk/Jmol opened as an automatic project. (Test File and Debug Test File work.)
This seems to happen whenever JUnitAntLogger.getOutputReader() is called. JUnitAntLogger.getOutputReader() tries to get the project by calling FileOwnerQuery.getOwner() and then calls JUnitOutputReader() JUnitOutputReader() tries to get the project again by calling FileOwnerQuery.getOwner() and then calls JUnitTestSession(), which used to raise the NPE before the assert statement from comment 3 was added In both cases the project returned by FileOwnerQuery.getOwner() is null. I do not know why this happens. One solution would be to just consume the AntEvent in JUnitAntLogger that triggered the call to JUnitAntLogger.getOutputReader() when the project that is returned by FileOwnerQuery.getOwner() is null. Jesse any thoughts on that? Thanks
I think the problem is the reliance on event.getProperty("basedir"). There is no clear reason why this code is there; the basedir need have nothing to do with the test being run. Nor does event.getProperty("work.dir") make much sense. I would delete both of these. But then, I do not really see that the project parameter is being used for at all. All of this code mishandles nulls all over the place, and makes all kinds of unfounded and undocumented assumptions; it needs to be rewritten, but in the meantime this NPE is critical. I am trying out some patches which I will attach for your review.
Still reproducible via comment #9, unless run from ant tryme and cachedir is nbbuild/testuserdir/var/cache - in which case nbbuild is considered the "owner" of the test, because of junit-snippet.xml used for CoS test runs, which is of course nonsense. (For whatever reason, work.dir is set by Test File and Debug Test File, but not by Profile Test File, hence the bug setup.) The org.netbeans.modules.junit.output code I see is wrong from start to finish. propsOfInterest, work.dir, basedir - these are all properties which may or may not be set to unspecified values, according to the script which ran JUnit; the logger should not be paying attention to _any_ of this because it cannot know what it means. originatingScript is also meaningless in JUnitOutputReader: who cares which script started the build? That script might have called a different script which called a third script which ran JUnit. All this code must be rewritten to use AntEvent.taskStructure to inspect the actual call to <junit> (or <java>) which is triggering display of the result window. Use <test>, <batchtest>, <classpath>, etc. to figure out what tests are actually being run and where they are located (in binaries; use SourceForBinaryQuery to find matching sources). That also means getOutputReader may only be called inside taskStarted or taskFinished methods, or messageLogged nested inside one of these. buildFinished, if still needed, must do something different (e.g. use a custom logger state object to keep track of a set of JUnit runs encountered during the current build). Some other mistakes: FileUtil.toFileObject(antScript) is called without checking for a null return value. TestSession should not need to be passed a Project parameter (see blocking issue). ProjectFileLocator may not look for "platform.active" in a project's evaluator since this is only sensible for certain project types; should simply inspect ClassPath.BOOT for the tests actually being processed, if it needs to know this information at all. Nor should it be calling ProjectUtils.getSources(p) (which BTW can never return null so do not check for it!), since it is irrelevant what source roots some nearby project might have - what you care about is a single binary classpath, what is being run right now.
core-main #68eef6939041
*** Bug 191217 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/68eef6939041 User: Jesse Glick <jglick@netbeans.org> Log: #187004: [69cat] NullPointerException: The project parameter cannot be null Hot fix; real bug runs deeper.