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.
Each invocation of New Action wizard leaves many instances leaked (up to 2MB worth of heap). See the attached list of leaked instances after 2nd invocation of the wizard (the instances with +something in the Difference column). Many of the reference graphs end up in the static hashmap of GUIRegistrationPanel, so this is most probably the core cause of the leak. See another attachment.
Created attachment 27641 [details] List of leaking instances
Created attachment 27642 [details] One of the reference paths ending in the static hasmap of GUIRegistrationPanel
Yes, thanks for investigation and for (offline) tips where the leak approximately is.
Created attachment 27643 [details] StreamPool instance which reference path is ending in static map of StreamPool
Seems that the cache is an unused history, forgotten there. Since current we are always reloading SFS data from scratch which wasn't the case in the initial implemtation IIRC. Quite nice catch, thanks!
Fixed. There shouldn't be problem with listeners. There could be one, but just innocent which could be potenitally attached multiply which doesn't mean too much from the performance and memory point of few (on object with short life-cycle). Checking in ui/wizard/action/GUIRegistrationPanel.java; 1.18 -> 1.19;
Verified partially fixed. However, part of leak still present. As we discussed offline, please, fix the static model in ActionTypePanel so that it is not static, but rather garbage collected and recreated each time. The problem is that now it holds its UI components forever through their listeners.
And I found two more classes with static models: NbPlatformCustomizerModules and CustomizerComponentFactory. Please, get rid of these too. THX.
Ok. As we spoke about it offline I think that there is a bug rather in JComboBox itself. If it registers any listener without knowledge of its client it should also handle removing it. I can write the fix for a JComboBox, it should be easy enough if I correctly understand to what addNotify and removeNotify methods are for and submit a bug to JDK team. From my point of view we just have a simple static model which is reasonably reused is our sources without nothing to fix from client's point of view. (even previous 'fix' (ActionTypePanel.java?r1=1.11&r2=1.12) was irrelevant if above is true). But it would be strange if they didn't do this intentionally. I'll try to explore it more deeply. Any hints/tips from UI experts are welcomed.
My opinion remains the same - even if theoretically a fix could be done on JDK side, we have no such option now. We support already released versions of JDK, and thus a fix on our side is a must. (This does not prevent you from filing the bug agains JDK of course, besides fixing it in your code...)
'...a fix on our side is a must...' Sure. Either it will be fixed or workarounded (JDK bug).
cvs ci -m "#70032: Maybe workarounding, may be not, possible leak in JComboBox and possibly elsewhere. I.e. switching from static to non-static models. As soos as I understand the details and/or intention I'll eventually file a bug agains JDK and revert this workaround." src/org/netbeans/modules/apisupport/project/ui/customizer/AddFriendPanel.java src/org/netbeans/modules/apisupport/project/ui/customizer/AddModulePanel.java src/org/netbeans/modules/apisupport/project/ui/customizer/CustomizerComponentFactory.java src/org/netbeans/modules/apisupport/project/ui/customizer/CustomizerDisplay.java src/org/netbeans/modules/apisupport/project/ui/platform/NbPlatformCustomizerModules.java src/org/netbeans/modules/apisupport/project/ui/wizard/action/GUIRegistrationPanel.java Checking in ui/customizer/AddFriendPanel.java; 1.3 -> 1.4; Checking in ui/customizer/AddModulePanel.java; 1.29 -> 1.30; Checking in ui/customizer/CustomizerComponentFactory.java; 1.2 -> 1.3; Checking in ui/customizer/CustomizerDisplay.java; 1.27 -> 1.28; Checking in ui/platform/NbPlatformCustomizerModules.java; 1.6 -> 1.7; Checking in ui/wizard/action/GUIRegistrationPanel.java; 1.19 -> 1.20;
> I'll eventually file a bug agains JDK and revert this workaround. Filing the JDK bug is not enough for reverting the workaround. When eventually the JDK bug is fixed and we stop supporting current versions of JDK, so some two or three releases of Netbeans from now, we can revert the workaround then.
Note that I filed separate issues #70364 and #70368 which contribute to the leak of New Action wizard. Besides these leaks, there still remain reference paths which hold leaked objects through staticly initialized renderers. See for example the following reference path org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel.POSITION_RENDERER-> org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel$PositionRenderer@1d1b6dc-> javax.swing.CellRendererPane@949cfe-> javax.swing.JComboBox@1707c77-> org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel@144b0d4-> ... We must get rid of the static renderers GUIRegistrationPanel.POSITION_RENDERER PlatformComponentFactory.URL_RENDERER (if I did not notice some static renderer, please fix those too)
Fixed in trunk. Presuambly should be backported into 5.0. I'll go through reviewers. Tondo could you review this for 5.0 branch? # GUIRegistrationPanel.POSITION_RENDERER test/unit/ui/wizard/action/GUIRegistrationPanelTest.java; 1.1 ui/wizard/action/GUIRegistrationPanel.form; 1.3 -> 1.4; ui/wizard/action/GUIRegistrationPanel.java; 1.20 -> 1.21; nbproject/project.properties 1.23 -> 1.24; # PlatformComponentFactory.URL_RENDERER ui/platform/NbPlatformCustomizerJavadoc.form; 1.3 -> 1.4; ui/platform/NbPlatformCustomizerJavadoc.java; 1.6 -> 1.7; ui/platform/NbPlatformCustomizerSources.form; 1.4 -> 1.5; ui/platform/NbPlatformCustomizerSources.java; 1.7 -> 1.8; ui/platform/PlatformComponentFactory.java; 1.5 -> 1.6; test/unit/ui/platform/NbPlatformCustomizerSourcesTest.java; 1.1
Diffs to be reviewed: http://apisupport.netbeans.org/servlets/ReadMsg?list=cvs&msgNo=2988 http://apisupport.netbeans.org/servlets/ReadMsg?list=cvs&msgNo=2989
I verified that the fix resolves the leak. WRT review, the code change looks good to me.
Backported into release50 (the same diff)
Verified in 5.0 (build 200512212030).