Bug 510155 - NullPointerException in SemanticUtil.substituteTypedef
Summary: NullPointerException in SemanticUtil.substituteTypedef
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 9.2.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-10 01:32 EST by EPP Error Reports CLA
Modified: 2020-09-04 15:26 EDT (History)
3 users (show)

See Also:


Attachments
parser log for issue (764.20 KB, text/x-log)
2017-10-17 15:35 EDT, Rob Clark CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description EPP Error Reports CLA 2017-01-10 01:32:22 EST
The following problem was reported via the automated error reporting:

Message: Error while parsing <path>.:Error resolving '_max2' in <path>.
java.lang.NullPointerException: null
    at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.SemanticUtil.substituteTypedef(SemanticUtil.java:433)
    at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.ExpressionTypes.restoreTypedefs(ExpressionTypes.java:75)
    at org.eclipse.cdt.internal.core.dom.parser.c.CASTBinaryExpression.getExpressionType(CASTBinaryExpression.java:252)
    at org.eclipse.cdt.internal.core.dom.parser.c.CASTUnaryExpression.getExpressionType(CASTUnaryExpression.java:119)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createBaseType(CVisitor.java:1369)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createType(CVisitor.java:1401)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createType(CVisitor.java:1251)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createBinding(CVisitor.java:791)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createBinding(CVisitor.java:744)
    at org.eclipse.cdt.internal.core.dom.parser.c.CVisitor.createBinding(CVisitor.java:478)
    at org.eclipse.cdt.internal.core.dom.parser.c.CASTName.resolveBinding(CASTName.java:63)
    at org.eclipse.cdt.internal.core.pdom.PDOMWriter.resolveNames(PDOMWriter.java:373)
    at org.eclipse.cdt.internal.core.pdom.PDOMWriter.addSymbols(PDOMWriter.java:270)
    at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.writeToIndex(AbstractIndexerTask.java:1277)
    at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseFile(AbstractIndexerTask.java:1094)
    at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseLinkage(AbstractIndexerTask.java:898)
    at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.runTask(AbstractIndexerTask.java:554)
    at org.eclipse.cdt.internal.core.pdom.indexer.PDOMIndexerTask.run(PDOMIndexerTask.java:161)
    at org.eclipse.cdt.internal.core.pdom.indexer.PDOMRebuildTask.run(PDOMRebuildTask.java:90)
    at org.eclipse.cdt.internal.core.pdom.PDOMIndexerJob.run(PDOMIndexerJob.java:137)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)


The reporter(s) left the following comment(s):

--- Anonymous wrote on 5947: ---
This was wierd beacase during the indexing time(you can see the progress bar in the bottom), the semantic color exist and the F3 key was able to jump to the proper place. but when finised, the semantic color hilighting is disapeard and F3 didn't work...

--- Anonymous wrote on 565f: ---
I imported linux kernel source code as 'Makefile project' in cdt, and configure the indexer on includes and macros. I think the problem was because the c file was too large(6000 lines) so as to too complicate to be parsed.

Bundles:
| org.eclipse.cdt.codan.checkers | 3.2.0.201602051005 | 3.2.0.201612061315 |
| org.eclipse.cdt.codan.core | 3.3.0.201602051005 | 4.0.0.201612061315 |
| org.eclipse.cdt.codan.core.cxx | 3.3.0.201602051005 | 3.4.0.201612061315 |
| org.eclipse.cdt.codan.ui | 3.2.0.201602051005 | 3.2.0.201612061315 |
| org.eclipse.cdt.core | 5.10.0.201506070905 | 6.2.0.201612061315 |
| org.eclipse.cdt.ui | 5.11.0.201509131935 | 6.1.0.201611160122 |
| org.eclipse.core.jobs | 3.7.0.v20150330-2103 | 3.8.0.v20161110-0346 |
| org.eclipse.e4.core.di | 1.5.0.v20150421-2214 | 1.5.0.v20150421-2214 |
| org.eclipse.jface | 3.11.1.v20160128-1644 | 3.11.1.v20160128-1644 |
| org.eclipse.jface.text | 3.10.0.v20150603-1752 | 3.11.100.v20161129-1710 |
| org.eclipse.ui | 3.107.0.v20150507-1945 | 3.107.0.v20150507-1945 |

Operating Systems:
| Linux | 2.6.32.1 | 4.9.0 |
| MacOSX | 10.10.5 | 10.12.2 |
| Windows | 6.1.0 | 10.0.0 |


The above information is a snapshot of the collected data. Visit https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/54c4ef5cbee810030da06d23 for the latest data.

Thank you for your assistance.
 Your friendly error-reports-inbox.


Created on behalf of zeratul976@xxxxxx.xxx
Comment 1 Nathan Ridge CLA 2017-01-10 01:33:16 EST
The common thread between reports of this problem seem to be parsing Linux kernel source code.

A small example would still be really helpful.
Comment 2 Rob Clark CLA 2017-10-17 15:35:56 EDT
Created attachment 271047 [details]
parser log for issue

So if it helps, I see the same issue (also with linux kernel).. seems to effect some files but not others.  I've attached parser log in case that helps.
Comment 3 Nathan Ridge CLA 2017-10-17 23:38:18 EDT
What would really help move this issue forward is a reduced code example that triggers the exception.
Comment 4 Rob Clark CLA 2017-10-18 09:38:58 EDT
(In reply to Nathan Ridge from comment #3)
> What would really help move this issue forward is a reduced code example
> that triggers the exception.

In at least one of the files that triggers this exception, it appears to be related to use of the min/max macros in include/linux/kernel.h:


/*
 * min()/max()/clamp() macros that also do
 * strict type-checking.. See the
 * "unnecessary" pointer comparison.
 */
#define __min(t1, t2, min1, min2, x, y) ({		\
	t1 min1 = (x);					\
	t2 min2 = (y);					\
	(void) (&min1 == &min2);			\
	min1 < min2 ? min1 : min2; })
#define min(x, y)					\
	__min(typeof(x), typeof(y),			\
	      __UNIQUE_ID(min1_), __UNIQUE_ID(min2_),	\
	      x, y)

#define __max(t1, t2, max1, max2, x, y) ({		\
	t1 max1 = (x);					\
	t2 max2 = (y);					\
	(void) (&max1 == &max2);			\
	max1 > max2 ? max1 : max2; })
#define max(x, y)					\
	__max(typeof(x), typeof(y),			\
	      __UNIQUE_ID(max1_), __UNIQUE_ID(max2_),	\
	      x, y)


from include/linux/compiler.h:

/* Indirect macros required for expanded argument pasting, eg. __LINE__. */
#define ___PASTE(a,b) a##b
#define __PASTE(a,b) ___PASTE(a,b)

... snip ...

/* Not-quite-unique ID. */
#ifndef __UNIQUE_ID
# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
#endif
Comment 5 Nathan Ridge CLA 2017-10-18 11:38:58 EDT
The code from comment 4 does not reproduce the exception.

Based on the stack trace, code consisting purely of preprocessor definitions will not trigger the exception. While the problem may be related to those macros, the code example will also need to include some code that calls (invokes) those macros.
Comment 6 Rob Clark CLA 2017-11-06 19:52:02 EST
(In reply to Nathan Ridge from comment #5)
> The code from comment 4 does not reproduce the exception.
> 
> Based on the stack trace, code consisting purely of preprocessor definitions
> will not trigger the exception. While the problem may be related to those
> macros, the code example will also need to include some code that calls
> (invokes) those macros.

sorry, been busy and haven't had time to create a reproducer, but I guess it should be easy enough to write some dummy code that uses the min/max macros based on what I described..

for now, I just added an:

#ifdef ECLIPSE_HACKS
#  undef min
#  undef max
#endif

and defined ECLIPSE_HACKS=1 in project properties -> 'C/C++ General' -> 'Paths and Symbols' to workaround the bug