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.
Step to reproduce: - open large project (for example boost) - wait parsing finished (or switch off code model) - restart IDE - look at memory - invoke project properties. Close by cancel. - see memory increase (in my configuration of boost I have 16M). Additional memory do not released by GC. It not Ok, but it is low priority bug - invoke project properties 10 times. - see memory increase at each iteration (in my configuration of boost I have 160M). IMHO it is a P1 bug. Memory investigation show following memory leak at each iteration: IntConfiguration +215,340 (+6,890,880) StringConfiguration +124,367 (+2,985,024) BooleanConfiguration +94,915 (+2,277,960) VectorConfiguration +51,056 (+1,225,340) OptionsConfiguration +37,749 (+905,976) CCCompilerConfiguration +12,704 (+1,016,320) CCompilerConfiguration +12,822 (+1,025,760) FortranCompilerConfiguration +12,219 (+586,512) CustomToolConfiguration +12,218 (+293,232) ItemConfiguration +6,109 (+293,232) Total: (+16,274,887)
problem class is ToolsPanel, static field: static Set<ChangeListener> listenerModified = new HashSet<ChangeListener>(); When properties panel showing the MakeCustomizerProvider, the new cloned descriptor created: ConfigurationDescriptor clonedProjectdescriptor = projectDescriptorProvider.getConfigurationDescriptor().cloneProjectDescriptor(); In clone added listener. After dialog closing the cloned descriptor do not delete listener.
fixed in release65_cnd_freeze branch, change set: http://elif.russia.sun.com/hg/release65_cnd_freeze/rev/4bc625e995b2
I agree with suggested fix.
reproducible in dev build 2008-10-03--15-12
please, retest. What you should test: - start IDE with opened boost - wait initial parsing - invoke project properties - wait (10 seconds) and invoke force GC 3 times, remember memory (consumed, not allocated). - invoke project properties 5 times - wait (10 seconds) and invoke force GC 3 times, compare memory. Expected: consumed (not allocated) memory was not increased (difference +- 10M)
Indeed I did not call garbage collector before. Now the behavior is the same as expected so the issue can be treated as fixed and verified in dev build 2008-10-03--15-12.
fixed in main trunk, change set: http://hg.netbeans.org/main/rev/482ae4e1c598
Integrated into 'main-golden', will be available in build *200810070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/482ae4e1c598 User: Alexander Simon <alexvsimon@netbeans.org> Log: fixed: IZ#149032:memory leak in make project