Description of problem: Memory usage of the browser tab containing the user portal increases until the browser has exhausted the available memory. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Log into the user portal with an admin level user. 2. Switch to the extended tab, then click the 'resources' tab on the left. 3. You will get to the resources screen which contains a tree table with information about the VMs. You will also notice a refresh timer. Set the timer to 5 seconds. 4. Open up an application that can monitor memory usage of the browser. For instance the task manager in windows. 5. Wait and watch the memory usage of the browser grow and grow. Actual results: Memory increases until available memory is exhausted. Expected results: Memory increases until unused objects are garbage collected and memory usage drops again. Additional info:
Unable to reproduce on Firefox 18. Please provide more details (browser + version, OS) Thanks
Well it is hard to identify memory leaks in FF. Try in either Chrome or IE8. Instructions for IE8: Open up your IE8, and open up the task manager. Browse to the extended tab resources tab. Note the memory usage by the iexplorer process. Hit refresh a few times or just wait for the refresh timer to fire a couple of times. You will notice the memory usage of iexplorer will increase each time you hit refresh. Instructions for Chrome: I highly suggest you compile GWT in detailed mode as the Chrome memory profiler will provide you with information on which objects are leaking. Open up Chrome, log into the user portal, switch to the extended tab, select the resources tab. Press CTRL-SHIFT-I. This will open up the Chrome developer tools. Click on the 'Profiles' button. In the profiles tab, click the 'Take Heap Snapshot' selection box. Then click start. This will take a memory snapshot. Go back to the browser, and hit refresh a couple of time or let the timer refresh for a while. Go back to the developer tools and take another snapshot. You will notice that the second snapshot uses more memory (this doesn't mean a leak as some stuff might not have been garbage collected). On the second snapshot, at the bottom of the window you can click and change the summary/overview to comparison. It should automatically select the other snapshot. The window will now display all the objects in memory and the deltas. You should see a bunch of objects with +<number> which means there are more of those in the second snapshot than there were in the first one. If you compiled in detailed mode you should get some indication of what objects those are and were to start looking for the leak.
Thanks for the detailed instructions. I have found a memory leakage of about 5MB per hour. Alexander, Does this numbers match your findings? On the general, I run the same process over Basic View and VM tab as well. they all seem to produce the same results. Resources tab +959,264 B Basic View +1,103,312 B Vm tab +673,672 B *for 10 minutes
Well the memory leak depends on the number of VMs and how you compile the software (in detailed mode it leaks more memory than obfuscated mode). We were seeing much higher leakage. In the 20-40M per refresh. In general what we saw was one or both of the following issues: 1. Event handlers being attached to UserPortalItemModel or UserPortalItemListModel, without being removed when new data arrived. Those are usually slower leaks. 2. Circular references to entities and UserPortalItemModel or UserPortalItemListModel. Which would cause the entire entity and associated views to not be garbage collected when new data arrives. These are usually faster leaks, in the tens of megabytes per refresh. We have found and fixed most of those memory leaks in some other patches that are about to make it into the master. The only one we found but didn't fix is the one on the resources tab. I put in this bugzilla so we wouldn't forget to actually fix the memory leak.
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)