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.
This issue was reported manually by alexvsimon. It already has 1 duplicates Build: NetBeans IDE 8.1 Beta (Build 201508041349) VM: Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Java(TM) SE Runtime Environment, 1.8.0_51-b16 OS: Windows 8.1 User Comments: GUEST: Editting a C++ program in the IDE Stacktrace: java.lang.AssertionError at org.clang.tools.services.impl.PreprocessorInitializer.clearFileCache(PreprocessorInitializer.java:144) at org.clang.tools.services.ClankPreprocessorServices.invalidate(ClankPreprocessorServices.java:75) at org.netbeans.modules.cnd.apt.impl.support.clank.ClankDriverImpl.invalidateImpl(ClankDriverImpl.java:93) at org.netbeans.modules.cnd.apt.impl.support.clank.ClankDriverImpl.invalidateImpl(ClankDriverImpl.java:100) at org.netbeans.modules.cnd.apt.support.ClankDriver.invalidate(ClankDriver.java:271) at org.netbeans.modules.cnd.modelimpl.csm.core.ProjectImpl.onFileEditStart(ProjectImpl.java:164)
Created attachment 155440 [details] stacktrace
*** Bug 254919 has been marked as a duplicate of this bug. ***
All reports concern 8.1 beta. So it should be based on sputnik #changeset: 15335:5464dcd6a07f which contains assert path.is_absolute(new Twine(Path)); in PreprocessorInitializer.clearFileCache(PreprocessorInitializer.java:144) So it should be an error in path.is_absolute() I guess (since the path comes from file system listener, FileBuffer.getAbsoultePath(), etc - so it is guaranteed to be absolute) I think this has been already fixed.
Just in case I'm wrong I added better assertion (with path): https://hg.kenai.com/hg/sputnik~main/rev/0c3bb505ffa2
Alexander, what is the reason for reopening this bug? I still see only one exception report for 8.1 Beta in the list.
But may be you met the intermediate state of libs.clank where the NPE was fixed as c4b73a8e97df in sputnik
(In reply to Vladimir Voskresensky from comment #5) > Alexander, what is the reason for reopening this bug? I still see only one > exception report for 8.1 Beta in the list. Because the bug #262442 thinks that this bug reproduced again.
Ok. then let's fix the problem in mentioned bug #262442