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.
With every (JUnit for me) test action the memory consumption is growing. The amount of memory depends on the amount of output the test generates. I can even reproduce OOME (heap size approx. 750M) with less then 10 test runs with a single test. The cause is imo InputOutput component is never GCed. There seems to be two reasons. The first one is the value in WeakHashMap in org.netbeans.modules.gsf.testrunner.api.Manager.displayHandlers references the key so it is never GCed. The second one is the core.output2 infrastructure holds InputOutput until the closeInputOutput is called but gsf.testrunner never does that.
Created attachment 122277 [details] possible fix This patch seems to be working - resolving both issues. OTOH I'm not an expert in gsf.testrunner. I think I could provide a better patch at cost of changing gsf.testrunner friend api. I'll try that tomorrow.
BTW Jardo, is it ok that io infrastructure holds strong reference of io created for custom container?
Created attachment 122292 [details] simplified patch I originally thought this would be api change, but the ResultWindow is package private. So this is simplified patch without any api change.
(In reply to comment #2) > BTW Jardo, is it ok that io infrastructure holds strong reference of io created > for custom container? It is not ideal, but it works correctly if clients close all created IO objects. It may be improved in the future. For now adding a note to JavaDoc: http://hg.netbeans.org/core-main/rev/871ef973c899
Theofanis, I can integrate the patch for you. Let me know whether I should do that.
Petr, thank you for the patch. Seems fine to me. I will go ahead and integrate it tomorrow.
Created attachment 122347 [details] final patch I am attaching the patch I am going to integrate. I think there is no need to increase the spec version. Also, I am reverting the conversion of ResultWindow.addDisplayComponent from public to package private. Was there a reason for that? If there are no objections I will integrate later today. Thank you
(In reply to comment #7) > Created attachment 122347 [details] > final patch > > I am attaching the patch I am going to integrate. I think there is no need to > increase the spec version. Also, I am reverting the conversion of > ResultWindow.addDisplayComponent from public to package private. Was there a > reason for that? No particular reason. I thought ResultWindow was an api, but it is not. > If there are no objections I will integrate later today. Thank > you Ok.
Integrated into core-main: http://hg.netbeans.org/core-main/rev/50141649f597
Integrated into 'main-golden', will be available in build *201207260002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/871ef973c899 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #215847: JavaDoc - Inform users that InputOutput objects should be explicitly closed when using custom IOContainer
Mariáne, this is a patch candidate, right?
sure ... integrate into release72 branch once verified in trunk, see http://wiki.netbeans.org/NetBeansPatchesProcess
verified in trunk, please proceed with transplant
transplanted to release72 - http://hg.netbeans.org/releases/rev/41472194bf52
Integrated into 'releases', will be available in build *201209010822* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/41472194bf52 User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #215847 - Severe memory leak in gsf.testrunner (transplanted from 50141649f597d7bb88427f6e6801f86e00c73d23)