Success! Looks like we've fixed this one. According to our records the fix was applied for EXTJS-9794 in a recent build.
  1. #1
    Touch Premium Member
    Join Date
    Nov 2009
    Location
    London
    Posts
    49
    Vote Rating
    6
    mattgoldspink is on a distinguished road

      2  

    Default Ext association memory leak

    Ext association memory leak


    Hi,
    It looks like there is a memory leak in Ext 4.2 when using associations. I've created a simple page which creates one model with a has many association & on clicking a button uses the store loadRawData api to load it in.

    Code:
        var userDataSet = [], storeToTest;
    
    
        userDataSet.push({
            id: 1,
            orders: [{
                id: 1
            }]
        });
    
    
        Ext.define('User', {
            extend: 'Ext.data.Model',
            fields: ['id'],
    
    
            hasMany: {model: 'Order', name: 'orders'}
        });
    
    
        Ext.define('Order', {
            extend: 'Ext.data.Model',
            fields: ['id']
        });
    
    
        Ext.define('UserStore', {
            extend: 'Ext.data.Store',
            model: 'User'
        });
    
    
        storeToTest = new UserStore();
    
    
        function doStoreLoad() {
            storeToTest.loadRawData(userDataSet);
            document.getElementById('count').innerHTML = Ext.StoreMgr.getCount();
        }
    (running version at: http://jsbin.com/opakuz/1/edit)

    I've run this in chrome and taken several heap dump, whilst clicking & adding a new set of data to the store. As you can see in the below screenshots of the profiler the number of objects between each subsequent load of the store goes up by 43 Objects each time. This seems a little too consistent and sounds like it could be a bug in the framework. I know we've certainly had memory issues with Ext and Associations, but I've not been able to pin point the issue.

    ext-association-mem-leak-3-2.jpg

    Difference between snapshot 2 & 3

    ext-association-mem-leak-3-4.jpg

    Difference between snapshot 3 & 4

    ext-association-mem-leak-4-5.jpg

    Difference between snapshot 4 & 5

    Note I've also forced a GC inbetween calls.

    Is there a known memory leak when using associations?

    Thanks,
    Matt

  2. #2
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    4,795
    Vote Rating
    167
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default


    Thanks for the report! I have opened a bug in our bug tracker.

  3. #3
    Sencha User
    Join Date
    Nov 2011
    Posts
    21
    Vote Rating
    4
    Navaar is on a distinguished road

      0  

    Default


    Our ExtJS 4.2 app uses assoications heavily and we have noticed the same thing. Have not yet been able to pin down a cause. Hopefully this will make the 4.2.1 release.

  4. #4
    Sencha - Ext JS Dev Team
    Join Date
    Jun 2011
    Location
    San Diego, CA
    Posts
    179
    Vote Rating
    35
    nohuhu has a spectacular aura about nohuhu has a spectacular aura about

      0  

    Default


    @Navaar It did in fact.

    Regards,
    Alex.

  5. #5
    Sencha User
    Join Date
    Jan 2014
    Posts
    5
    Vote Rating
    0
    esscotti is on a distinguished road

      0  

    Default patch?

    patch?


    We think we have a problem with this issue in our current project which was based on ExtJs 4.2.

    Unfortunately we are due to deliver in the next few days and are not able to upgrade our ExtJs as we would have to re-run the whole test cycle.

    Is there any chance that this fix can be implemented as a patch? Which code was updated to implement this fix?

    Many thanks for any help or advice.

  6. #6
    Sencha - Ext JS Dev Team
    Join Date
    Jun 2011
    Location
    San Diego, CA
    Posts
    179
    Vote Rating
    35
    nohuhu has a spectacular aura about nohuhu has a spectacular aura about

      0  

    Default


    esscotti,

    Which Ext version you're using? The fix was shipped with 4.2.1.

    Regards,
    Alex.

  7. #7
    Sencha User
    Join Date
    Jan 2014
    Posts
    5
    Vote Rating
    0
    esscotti is on a distinguished road

      0  

    Default


    Thanks for the reply, Alex. Our project is based on Ext 4.2.0.

    My current approach is to try to diff the two versions and try to come up with an override that I can use in my project until we can upgrade to the latest and greatest. Nu luck as yet..

  8. #8
    Sencha - Ext JS Dev Team
    Join Date
    Jun 2011
    Location
    San Diego, CA
    Posts
    179
    Vote Rating
    35
    nohuhu has a spectacular aura about nohuhu has a spectacular aura about

      0  

    Default


    esscotti,

    I would suggest updating to 4.2.1, or even better, to 4.2.2 - there was a ton of bug fixes since 4.2.0. If you absolutely can't update the framework, ask the support folks to provide you a custom patch.

    Regards,
    Alex.

  9. #9
    Sencha User
    Join Date
    Jan 2014
    Posts
    5
    Vote Rating
    0
    esscotti is on a distinguished road

      0  

    Default


    Thanks, we'll definitely need to update our project soon.

    For now, I found a work around. Just wanted to post it in case anyone else might benefit...

    We had the following in our code, dealing with a data set that is quite large..
    ...
    store.removeAll();
    store.loadRawData(data);
    ...

    Data thet had been loaded into the store before removeAll() was never freed it seemed and heap size grew and grew until the browser crashed.

    I discovered that adding commitChanges() allowed the data to be freed so this works for me as a workaround..
    ...
    store.removeAll();
    store.loadRawData(data);
    store.commitChanges();
    ...

    Thanks again for your support..

    PS. we also changed the model from using hasMany to instead using a model field that held an array, but I don't think that was what fixed the issue as the memory leak existed even after that..