View Full Version : Serious memory leak

17 Jul 2012, 1:17 AM
Hi to all,
I'm using ext.net from a while and currently we're investigating the adoption of extjs (ext.net) framework for all our products. However a lot of functions are related on showing real time data and we found a serious memory leak in the 4.1.1 version.<br><br>Using the sample <a data-cke-saved-href="http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/charts/LiveUpdates.html" href="http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/charts/LiveUpdates.html">http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/charts/LiveUpdates.html</a>&nbsp;&nbsp; in explorer we join over 500MB in few minutes, the same in firefox and chrome.
I slightly changed the generateData function in&nbsp;&nbsp;LiveUpdates.js to delete the 11th element in the array:
if(data.length&gt;10) {

but the problem persist. Any idea if the problem is already known and when it will be fixed?
Thanks in advance

17 Jul 2012, 2:24 AM
Its not a bug in the framework but in the sample. the data of the store grows each interval with 1 item.

Thats because generateData is appending 1 record to the store each interval. Its a badly programmed sample.

17 Jul 2012, 2:54 AM
Thanks for your answer I saw it and I changed the sample removing all the items in the store for each refresh

window.generateAllData = function(){
window.setTimeout("generateAllData()", 1000);

but the problem is still there in 5 minutes it has fired almost 6 MB of memory...
Any ideas?

17 Jul 2012, 3:23 AM
Clearing the store doesn't matter. loadData will do that. It's something in the function generateData.
It produces each interval an extra record. Maybe because it relies on previous data. Taken of the first record in the data array should probably stop the leak.

But I am not very familiar with this sample, I think the way in wich the data is generated causes the leak. And that part is not part of the sencha framework.

So you should search in the generateData function.

The chart must be fed with new data , but this dataset may not grow :)

17 Jul 2012, 4:54 AM
Thanks tvanzoelen for your help you're right removeAll doesn't matter. I simplified the sample and I observed the behavior in 3 cases:

1. Just recreating the array No memory leak in 10 minutes
2. Recreating the array and loading them in the store No memory leak in 10 minutes
3. Recreating the array, loading them in the store and update the gauge MEMORY leaks!!!

So according to my tests it seems there is a memory leak in gauges, now I'll try it in the grid

Any help????
p.s. attached you can find a simplified version of the gauge sample to verify the leaking

17 Jul 2012, 5:02 AM
I cannot find a js in your zip

17 Jul 2012, 5:04 AM
The javascript is embedded in the html page


17 Jul 2012, 5:59 AM
Isn't this allways

i < (n || 12)

count to 12?

You put n =1 in. But it will count to 12. Is that what you want?

17 Jul 2012, 6:06 AM
it's part of the sample :) it loads n if you pass n to the function generateData the default value is 12

In the sample I use n=1 so it loads just one sample with a name and 3 data fields to populate the gauges. If you leave the comments there isn't any leaks but if you uncomment the part where gauges are bound to the stores you can see the problem

thanks again

18 Jul 2012, 7:22 AM
Any help ??