Red Hat Bugzilla – Bug 1020547
Memory leak when closing dialog through UI plugin framework
Last modified: 2016-02-10 14:22:45 EST
Description of problem: Our application is a plugin for the UI and utilizes several dialogs that are opened using the plugin framework API openDialog(). The dialog shows content inside an iframe. When the dialog is closed, the memory taken when the dialog was opened is not released. Note that this seems to be occurring both in IE 9/10 and Mozilla web browsers. Version-Release number of selected component (if applicable): oVirt 3.3 How reproducible: Steps to Reproduce: 1. Create a basic UI plugin that adds a button somewhere in the UI that once clicked opens a dialog with any web page inside of it. It's easiest to see with a page that increases the memory usage significantly like another GWT app. 2. Watch the memory usage through Task Manager and open the dialog. 3. See that the memory rises as the page is loaded in the frame. 4. Close the dialog and see that the memory is not released. 5. Open the dialog again and the memory continues to increase. Actual results: Expected results: The memory should be freed when the dialog closes. Additional info:
Hi Chris, thanks for reporting this issue! Does the memory leak occur when closing the dialog using built-in mechanism (dialog close icon, Escape key), or using plugin API (api.closeDialog function), or both? Each custom dialog opened via plugin API (api.showDialog function) is disposable (non-singleton) so most likely we're keeping a reference to the dialog class and/or its iframe element even after it's closed. I'll need to investigate this. Chris, how severe is this issue?
setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.
This is an automated message. Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
Hi Vojtech, Sorry for not getting back sooner on this. The issue definitely needs to be fixed at some point. We've just released and so far haven't hit any major issues with customers, but it could become a problem. In general a known memory leak like this really should be fixed if at all possible.
This is an automated message. oVirt 3.4.1 has been released. This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still an issue.
Ok to close. No longer an issue for us.