Bug 110270 - Failure in model test 20050921-1200
Summary: Failure in model test 20050921-1200
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M3   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-21 19:12 EDT by Olivier Thomann CLA
Modified: 2005-10-30 07:01 EST (History)
1 user (show)

See Also:


Attachments
Proposed fix (1.22 KB, patch)
2005-09-21 19:50 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed fix (1.37 KB, patch)
2005-09-22 14:51 EDT, Olivier Thomann CLA
no flags Details | Diff
New patch (5.33 KB, patch)
2005-09-28 09:55 EDT, Olivier Thomann CLA
no flags Details | Diff
New patch (14.19 KB, patch)
2005-09-28 10:15 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2005-09-21 19:12:05 EDT
The test failed with a NPE.

Here is the stack trace.

java.lang.NullPointerException
at
org.eclipse.jdt.core.dom.CompilationUnit.setLineEndTable(CompilationUnit.java:199)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.convert(CompilationUnitResolver.java:252)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:810)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:588)
at
org.eclipse.jdt.core.tests.dom.ConverterTestSetup.runConversion(ConverterTestSetup.java:133)
at
org.eclipse.jdt.core.tests.dom.ASTConverterBindingsTest.checkBindingEqualityForProject(ASTConverterBindingsTest.java:518)
at
org.eclipse.jdt.core.tests.dom.ASTConverterBindingsTest.test0001(ASTConverterBindingsTest.java:493)
at
org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.runTest(SuiteOfTestCases.java:99)
at
org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.superRun(SuiteOfTestCases.java:83)
at
org.eclipse.jdt.core.tests.model.SuiteOfTestCases$1.protect(SuiteOfTestCases.java:71)
at
org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.run(SuiteOfTestCases.java:80)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:313)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:199)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:35)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:31)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:377)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:164)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:338)
at org.eclipse.core.launcher.Main.basicRun(Main.java:282)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)

I don't see why a NPE is thrown if the argument is null.
void setLineEndTable(int[] lineEndTable) {
	if (lineEndTable == null) {
		throw new NullPointerException();
	}
	// alternate root is *not* considered a structural property
	// but we protect them nevertheless
	checkModifiable();
	this.lineEndTable = lineEndTable;
}

There is no need to throw a NPE. if the argument is null, an empty array should
be set as the lineEndTable. Then
org.eclipse.jdt.core.dom.CompilationUnit.lineNumber(int position) would work as
specified.
Comment 1 Olivier Thomann CLA 2005-09-21 19:50:26 EDT
Created attachment 27369 [details]
Proposed fix

With this patch, no NPE will be thrown anymore.
Comment 2 Philipe Mulet CLA 2005-09-22 03:18:12 EDT
Seems a bit of a hack to allow convert null values.
Why is someone setting a null table in there ? Is this platform dependant ?
Comment 3 Philipe Mulet CLA 2005-09-22 03:21:32 EDT
Normal senders should at least pass an empty table (Scanner.EMPTY_LINE_ENDS)
Comment 4 Philipe Mulet CLA 2005-09-22 03:25:06 EDT
I think there must be a path in the code where the parsed unit doesn't retrieve
the lineEnds from scanner before reaching this point.
Comment 5 Olivier Thomann CLA 2005-09-22 06:57:26 EDT
This would be possible if the scanner didn't record the line ends.
We might want to add an empty array when the line ends are persisted. What is
suspicious is the fact that this test suddendly failed without any changes from
our side.
Also the patch is not a hack. The NPE is not specified and doesn't add anything.
Comment 6 Olivier Thomann CLA 2005-09-22 14:51:51 EDT
Created attachment 27404 [details]
Proposed fix
Comment 7 Olivier Thomann CLA 2005-09-28 09:55:59 EDT
Created attachment 27613 [details]
New patch
Comment 8 Olivier Thomann CLA 2005-09-28 09:57:10 EDT
This patch ensures that null is never passed to the setLineEndTable(). If null
is about to be passed, we convert it to an empty array.
Comment 9 Olivier Thomann CLA 2005-09-28 10:15:53 EDT
Created attachment 27615 [details]
New patch

I moved the logic on the compilation result class.
Comment 10 Olivier Thomann CLA 2005-09-28 11:00:29 EDT
Fixed and released in HEAD.
Tests should not fail anymore with NPE.
Comment 11 Frederic Fusier CLA 2005-10-30 07:01:02 EST
Verified for 3.2 M3 using build I20051025-0800+v_619