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.

Bug 121299

Summary:	AssertionError when reconfiguring Boost
Product:	cnd	Reporter:	Vladimir Kvashin <vkvashin>
Component:	Code Model	Assignee:	Vladimir Kvashin <vkvashin>
Status:	VERIFIED FIXED
Severity:	blocker
Priority:	P1
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Attachments:	the stack patch to branch "release6.0"

Description Vladimir Kvashin 2007-11-06 15:24:22 UTC

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)

Comment 1 Vladimir Kvashin 2007-11-06 15:26:11 UTC

Created attachment 52607 [details]
the stack

Comment 2 Alexander Simon 2007-11-07 17:29:40 UTC

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

Comment 3 Alexander Simon 2007-11-07 17:31:16 UTC

Created attachment 52674 [details]
patch to branch "release6.0"

Comment 4 Vladimir Kvashin 2007-11-07 17:41:56 UTC

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.

Comment 5 Jesse Grodnik 2007-11-07 17:49:03 UTC

Following NB 6 high resistance process

Comment 6 Vladimir Kvashin 2007-11-07 18:23:36 UTC

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.

Comment 7 Vladimir Kvashin 2007-11-07 18:29:06 UTC

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.

Comment 8 soldatov 2007-11-08 15:03:05 UTC

verified in trunk

Comment 9 soldatov 2007-11-12 13:13:04 UTC

verified first and second scenarios in RC1 build