Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 335668 - NPE in NodeModelBuilder.replaceWithoutChildren
Summary: NPE in NodeModelBuilder.replaceWithoutChildren
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-28 05:09 EST by Mark Christiaens CLA
Modified: 2017-09-19 17:55 EDT (History)
2 users (show)

See Also:
sebastian.zarnekow: indigo+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Christiaens CLA 2011-01-28 05:09:12 EST
Build Identifier: 20100917-0705

In a unit test I'm parsing the string

work.cpu_types.status_value'(work.cpu_types.fetch)

It fails due to a NPE in 

Thread [main] (Suspended (exception NullPointerException))	
	NodeModelBuilder.replaceWithoutChildren(AbstractNode, AbstractNode) line: 316	
	NodeModelBuilder.replace(AbstractNode, AbstractNode) line: 276	
	NodeModelBuilder.compressAndReturnParent(ICompositeNode) line: 194	
	InternalVHDLLangParser(AbstractInternalAntlrParser).parse(String) line: 548	
	VHDLLangParser(AbstractAntlrParser).doParse(String, CharStream, NodeModelBuilder) line: 101	
	VHDLLangParser(AbstractAntlrParser).parse(String, CharStream) line: 84	
	VHDLLangParser(AbstractAntlrParser).parse(ParserRule, Reader) line: 115	
	ParseExpressionTest(BaseVhdlLexerParserTest).getParseResult(Reader, ParserRule) line: 147	
	ParseExpressionTest(BaseVhdlLexerParserTest).checkParsing(Reader, ParserRule) line: 156	
	ParseExpressionTest(BaseVhdlLexerParserTest).checkParsing(String, ParserRule) line: 171	
	ParseExpressionTest.testParseQualifiedExpression() line: 88	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 616	
	ParseExpressionTest(TestCase).runTest() line: 168	
	ParseExpressionTest(TestCase).runBare() line: 134	
	TestResult$1.protect() line: 110	
	TestResult.runProtected(Test, Protectable) line: 128	
	TestResult.run(TestCase) line: 113	
	ParseExpressionTest(TestCase).run(TestResult) line: 124	
	TestSuite.runTest(Test, TestResult) line: 232	
	TestSuite.run(TestResult) line: 227	
	JUnit38ClassRunner.run(RunNotifier) line: 83	
	JUnit4TestMethodReference(JUnit4TestReference).run(TestExecution) line: 49	
	TestExecution.run(ITestReference[]) line: 38	
	RemoteTestRunner.runTests(String[], String, TestExecution) line: 467	
	RemoteTestRunner.runTests(TestExecution) line: 683	
	RemoteTestRunner.run() line: 390	
	RemoteTestRunner.main(String[]) line: 197	

The offending code seems to be

protected void replaceWithoutChildren(AbstractNode oldNode, AbstractNode newNode) {
		newNode.basicSetParent(oldNode.basicGetParent());
		if ((oldNode.basicGetParent()).basicGetFirstChild() == oldNode) {
			(newNode.basicGetParent()).basicSetFirstChild(newNode);
		}
		if (oldNode.basicGetNextSibling() == oldNode) {
			newNode.basicSetNextSibling(newNode);
		} else {
			newNode.basicSetNextSibling(oldNode.basicGetNextSibling());
			newNode.basicGetNextSibling().basicSetPreviousSibling(newNode);
		}
		if (oldNode.getPreviousSibling() == oldNode) {
			newNode.basicSetPreviousSibling(newNode);
		} else {
			newNode.basicSetPreviousSibling(oldNode.basicGetPreviousSibling());
			newNode.basicGetPreviousSibling().basicSetNextSibling(newNode);
		}
	}

In the first if-statement the oldNode.basicGetParent () is null. 


Reproducible: Always
Comment 1 Mark Christiaens CLA 2011-01-28 05:11:51 EST
I'm using the nightly build 2.0.0.v201101251647.

My other 8000+ parser tests succeed.
Comment 2 Sebastian Zarnekow CLA 2011-01-28 05:21:38 EST
Mark,

could you please provide a grammar that allows to reproduce the issue? 

Thanks,
Sebastian
Comment 3 Sebastian Zarnekow CLA 2011-02-01 07:52:42 EST
Fixed. The NPE was actually caused by a previous NoSuchMethodException that was shadowed by the subsequent NPE.
Comment 4 Karsten Thoms CLA 2017-09-19 17:43:59 EDT
Closing all bugs that were set to RESOLVED before Neon.0
Comment 5 Karsten Thoms CLA 2017-09-19 17:55:04 EDT
Closing all bugs that were set to RESOLVED before Neon.0