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.
Look at failure http://deadlock.netbeans.org/hudson/job/ergonomics/500/testReport/org.netbeans.test.ide/MemoryValidationTest/testGCProjects/ some CodeStylePreferences cache holds on project which is no longer open. private static final java.util.Map org.netbeans.modules.editor.indent.spi.CodeStylePreferences.cache-> java.util.WeakHashMap@5234e4-table-> [Ljava.util.WeakHashMap$Entry;@1db12be-[6]-> java.util.WeakHashMap$Entry@16f5dd0-value-> java.util.HashMap@1631925-table-> [Ljava.util.HashMap$Entry;@1a32600-[5]-> java.util.HashMap$Entry@135a7d2-value-> org.netbeans.modules.editor.indent.spi.CodeStylePreferences@32b11a-projectRoot-> org.netbeans.modules.projectapi.AuxiliaryConfigBasedPreferencesProvider$AuxiliaryConfigBasedPreferences@2c6271-this$0-> org.netbeans.modules.projectapi.AuxiliaryConfigBasedPreferencesProvider@1652383-project-> org.netbeans.modules.java.j2seproject.J2SEProject@18e7b75 You can run the java.kit/**/MemoryValidationTest.java locally on your computer, but the failure is random, you may not succeed reproducing it locally. I am making it P2, as it makes test in commit validation (randomly) fail, which is annoying, but the actual harm caused by this problem may not be so big.
Hmm, CodeStylePreferences.cache is a WeakHashMap, so either (1) somehow its keys can be held from its values or (2) Utilities.activeReferenceQueue() does not work correctly in the test. If #1 was the cause this memory leak should be reproducible. And because you say that the test fails randomly I think the problem is more likely in U.aRQ. But I'm not sure how to improve reliability of the test.
Project is referenced by WeakHashMap value: java.util.HashMap$Entry@135a7d2-value-> org.netbeans.modules.editor.indent.spi.CodeStylePreferences@32b11a-projectRoot-> org.netbeans.modules.projectapi.AuxiliaryConfigBasedPreferencesProvider$AuxiliaryConfigBasedPreferences@2c6271-this$0-> org.netbeans.modules.projectapi.AuxiliaryConfigBasedPreferencesProvider@1652383-project-> org.netbeans.modules.java.j2seproject.J2SEProject@18e7b75 but I do not see any way how it could be solved in editor.indent module. Passing to projectapi for evaluation.
fine, and since the org.netbeans.modules.projectapi.AuxiliaryConfigBasedPreferencesProvider needs the Project instance for working properly, we can close this issue and "live happily ever after". BTW: There are many scenarios I can imagine where project is *not* opened, but I want to the the proper code formatting rules for it's files.
My imagination does not generate any example that justifies CodePreferences being in memory if the project is closed, all editors are closed and there are no other opened components dealing with the project. We can leave as won'tfix until the commit validation fails again for similar reason.
*** Bug 176546 has been marked as a duplicate of this bug. ***
See duplicate for a more recent failure. I see these from time to time in C/V on cdev at least. I'm not sure what the Object keys are in this case, but if you can't do any better, keep the values in SoftReference's.
why is this still assigned to projects? -> editor
Not a 6.8 showstopper.
If I remember correctly I saw some failure reported by Jesse solved some time ago. I am closing this report as wontfix - if the problem is still there please post up to date chain of who is holding who and reopen. Or create a new issue and assign to component which should be fixed.