memory leak on destroy and reinstantiate

Ask for help relating to our Sencha Touch based Scheduler (for iPad, or any other supported phone, phablet or tablet)
Post Reply
User avatar
pincherhgz
Posts: 78
Joined: Mon Oct 27, 2014 11:40 am

memory leak on destroy and reinstantiate

Post by pincherhgz »

we are facing a significant memory leak on instantiating scheduler, destroying and instantiating again (see attached picture and example).

the example is your adapted zooming example, put it to your example structure and use buttons scheduler/destroy/scheduler
Attachments
reload.zip
(21.64 KiB) Downloaded 287 times
scheduler-memoryleak.png
scheduler-memoryleak.png (153.79 KiB) Viewed 6092 times

User avatar
mats
Core Developer
Core Developer
Posts: 16756
Joined: Sat Dec 19, 2009 11:41 pm
Location: Sweden
Contact:

Re: memory leak on destroy and reinstantiate

Post by mats »

Found a few interesting things that has been cleaned up. Could you please re-test in next available nightly build and see if your scenario has improved?
Tired of debugging javascript errors in web applications? Try our new error logging service RootCause, or read more on the Sencha blog

@bryntum
Facebook
API documentation

User avatar
pincherhgz
Posts: 78
Joined: Mon Oct 27, 2014 11:40 am

Re: memory leak on destroy and reinstantiate

Post by pincherhgz »

Hi, next build means today's nightly build. Yesterdays build still has the problem ? right ?

User avatar
mats
Core Developer
Core Developer
Posts: 16756
Joined: Sat Dec 19, 2009 11:41 pm
Location: Sweden
Contact:

Re: memory leak on destroy and reinstantiate

Post by mats »

Next one is tomorrow build
Tired of debugging javascript errors in web applications? Try our new error logging service RootCause, or read more on the Sencha blog

@bryntum
Facebook
API documentation

User avatar
mats
Core Developer
Core Developer
Posts: 16756
Joined: Sat Dec 19, 2009 11:41 pm
Location: Sweden
Contact:

Re: memory leak on destroy and reinstantiate

Post by mats »

Also note that you need to destroy these stores yourself:

Code: Select all

scheduler.eventStore.destroy();
            scheduler.resourceStore.destroy();
            scheduler.timeAxis.destroy();
Tired of debugging javascript errors in web applications? Try our new error logging service RootCause, or read more on the Sencha blog

@bryntum
Facebook
API documentation

User avatar
pincherhgz
Posts: 78
Joined: Mon Oct 27, 2014 11:40 am

Re: memory leak on destroy and reinstantiate

Post by pincherhgz »

the leak described is solved with this version, nevertheless we are facing memory leaks with the zoom function (see related report) and when we do drag and drop of events. Using your editor example you can see the number of objects not collected by GC on a simple drag and drop of one event (see attachment)
Attachments
scheduler-drag-drop_20151110.png
scheduler-drag-drop_20151110.png (193.77 KiB) Viewed 6076 times

User avatar
mats
Core Developer
Core Developer
Posts: 16756
Joined: Sat Dec 19, 2009 11:41 pm
Location: Sweden
Contact:

Re: memory leak on destroy and reinstantiate

Post by mats »

Let's continue the discussion in the relevant thread. Mem leak after drag and drop could not be confirmed, perhaps you can gather some more detailed 'proof' of what you're seeing? And please open a new thread for that.
Tired of debugging javascript errors in web applications? Try our new error logging service RootCause, or read more on the Sencha blog

@bryntum
Facebook
API documentation

Post Reply