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.
Steps to repeat are: - create a makefile-based project from boost sources - wait until it is parsed - reconfigure it (project explorer menu -> Code Assistance -> Configure code assistance) Project starts to parse (which is correct) At some moment AssertionError occurs (see the stack attached)
Created attachment 52607 [details] the stack
fixed in trank CVS log: Checking in csm/core/LibraryManager.java; /shared/data/ccvs/repository/cnd/modelimpl/src/org/netbeans/modules/cnd/modelimpl/csm/core/LibraryManager.java,v <-- LibraryManager.java new revision: 1.13; previous revision: 1.12 done Checking in platform/ModelSupport.java; /shared/data/ccvs/repository/cnd/modelimpl/src/org/netbeans/modules/cnd/modelimpl/platform/ModelSupport.java,v <-- ModelSupport.java new revision: 1.35; previous revision: 1.34 done
Created attachment 52674 [details] patch to branch "release6.0"
I've reviewed the attached patch. I consider it to be quite safe. At the same time I consider the issue is quite serious. So I believe it's worth applying this patch to release60. The issue is fixed only in trunk. So I'm reopening it.
Following NB 6 high resistance process
The patch contains two changes: 1) Don't fire item property change event for the projects that are being closed at the moment. This does not make sense and leads to exceptions. 2) Don't close required libraries when a bunch of files changes their properties. (Libraries are invisible for user containers for header files that are used though do not belong to user project - a container per used include search path) Such closure is incorrect.
The issue also repeats when user changes user-defined macros on the project level. If user changes this several times, this frequently leads to a bunch of exceptions.
verified in trunk
verified first and second scenarios in RC1 build