[TIMOB-1441] scrollview memory leak

Description

views:[],
showPagingControl:true,
pagingControlHeight:30,
maxZoomScale:2.0,
currentPage:1,

var img = Titanium.UI.createImageView({
    backgroundImage:'../hires/'+files[i],
    width:640,
    height:880,
    left:0,
    top:0,
});

var scroll = Titanium.UI.createScrollView({
    contentWidth:320,
    contentHeight:440,
    minZoomScale:0.5,
});

scroll.add(img);

scrollView.addView(scroll);

Attachments

Comments

1. gero 2011-04-15

   I can confirm this behaviour. Further information:

   • Creating a new context (window.url) does not help to release memory on close
   • Removing the window, the scrollable view or even every single view/image (removeView) on close does not help to release memory.
   • Setting every view to null or images to a smaller local image does not help to release memory on close.
   • If you call the scrollable view a second time with the same images (even in a new context), (almost) no further memory is consumed, which is a hint that the views persist in memory.

   This is a show stopper for every App with a "gallery". Release: 1.4.0 on iPhone 4.0.1.

2. David R. 2011-04-15

   Same problem here.

3. David R. 2011-04-15

   The TiUIImageView.m is missing a [imageView release] at line 308, I believe:

   http://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/TiUIImageView.m"> http://github.com/appcelerator/titanium_mobile/blob/master/iphone/C...

4. Stephen Tramer 2011-04-15

   Possibly already resolved by scrollview fixes to load/unload memory. Requires R&D.

5. Alan Leard 2011-04-15

   This issue may be causing the application to crash. See ticket reference: http://developer.appcelerator.com/helpdesk/view/73421">http://developer.appcelerator.com/helpdesk/view/73421

   Does not crash on iPhone 4. Does Crash on iPad and previous versions of iPhone. Does not crash on android.

   Use attached app to test.

6. bowman9991 2011-04-15

   Same here. 20 images on the iPad in a scrollView crashes every time, but iPhone works perfectly. Is a fix likely to make it into 1.6?

7. Marko Perutovic 2011-04-15

   Any news? This is critical to me!

8. DanielAndre 2011-04-15

   Same issue here. I am tired to run around this problem. The scrollableview is such a basic structure on an IPad. Please, i beg you, change this priority to high.

9. DanielAndre 2011-04-15

   Just to add some perspective. This bug is at least 8 months old.

   http://developer.appcelerator.com/question/46061/serious-memory-leak"> http://developer.appcelerator.com/question/46061/serious-memory-leak

10. Rick Blalock 2011-04-15

    Traces / Instrument files here.

    Crash Log and Console Log:
    http://pastie.org/1618663">http://pastie.org/1618663
    http://pastie.org/1618660">http://pastie.org/1618660

11. Stephen Tramer 2011-04-15

    There's another HD ticket for this: http://developer.appcelerator.com/helpdesk/view/64751">http://developer.appcelerator.com/helpdesk/view/64751

12. Jeff Haynie 2011-04-15

    (from [01937daa0e8379bb256b7b5d1e5a9ce675df397d]) [#1441 state:fixed-in-qa] Scollable view now unloads offscreen views. https://github.com/appcelerator/titanium_mobile/commit/01937daa0e8379bb256b7b5d1e5a9ce675df397d"> https://github.com/appcelerator/titanium_mobile/commit/01937daa0e83...

13. Jeff Haynie 2011-04-15

    (from [d000310a5b15c8cc03033617398835732178879d]) [#1441] Add adjustable caching to allow rendering performance/memory tradeoff. Sometimes the end dev knows best! https://github.com/appcelerator/titanium_mobile/commit/d000310a5b15c8cc03033617398835732178879d"> https://github.com/appcelerator/titanium_mobile/commit/d000310a5b15...

14. Jeff Haynie 2011-04-15

    (from [beb41c2c62bf67aac4d990b1d6e61dc31679724f]) [#1441] Fix for senseless caching values. Hat tip to Blain. https://github.com/appcelerator/titanium_mobile/commit/beb41c2c62bf67aac4d990b1d6e61dc31679724f"> https://github.com/appcelerator/titanium_mobile/commit/beb41c2c62bf...

15. Jeff Haynie 2011-04-15

    (from [757143515c9fef46bda05f0a703b179dd360ff66]) [#1441] When clearing the views array, actually deallocate the views https://github.com/appcelerator/titanium_mobile/commit/757143515c9fef46bda05f0a703b179dd360ff66"> https://github.com/appcelerator/titanium_mobile/commit/757143515c9f...

16. Rene Aavik 2011-04-15

    Hi,

    I don't think the issue is completely fixed. I am still experiencing app crashing when scrolling through a decent number number of hi-res images (necessary for my magazine app). Possibly a more fundamental issue with Titanium's garbage collecting routines?

17. Rene Aavik 2011-04-15

    I did some additional testing and here's what I discovered:

    • When scrolling through a set of images, new images are loaded to the cache, but the memory for previous (out of cache range) images is not freed, at least until:
    • when the available memory is very low (less than 10M on a mac running the iOS simulator), which is when GC seems to finally kick in and free some of the resources.
    • When running on device, GC seems to kick in too late, by that time it looks like iOS manages to force-quit the app that is gobbling up memory.

    I think the GC system Titanium uses for iOS apps needs some major improvements, and this is critical, as these issues make Titanium largely unusable for many times of projects. Unfortunately, I discovered this way too late (after investing more than a month of my time into a project that is almost complete, but still completely useless due to these memory issues).

    Developers working on this - please advise when you expect those major issues to be fixed? I realize the memory issues are scheduled for the 1.7.0 release, but I for one cannot afford to wait a couple of months on this, as I'm sure holds true to many others. I would even be willing to chip in on the development process to accelerate this, even though I am pretty new to Obj-C myself.

18. Brian 2011-04-15

    renx - I agree this is not fixed...we are experiencing the same issues with the latest build for 1.7. Also this is even worse with table views that have a lot of images...big showstoppers.

19. Stephen Tramer 2011-04-15

    We will be unable to address these specific issues without sample code.

20. Rene Aavik 2011-04-15

    I'm sorry, I should have posted the sample code. I also forgot to specify, that my ScrollableView does not consist of pure ImageViews, but instead of Views containing ImageViews (this is because my design requires there to be two images side-by-side in landscape view).

    However, it looks like memory is now being correctly released in the latest build of 1.7.0. I suspect the following commit did the trick:

    https://github.com/appcelerator/titanium_mobile/commit/b2209783baaee620d7600b7f8ef0117b87321d47"> https://github.com/appcelerator/titanium_mobile/commit/b2209783baae...

    as it seems to correct to properly detach all child views of a view being detached. This probably fixes this for situations where ImageViews are used as children in the ScrollableView.views array.

    I will do some additional testing on device and report back with sample code if I discover additional problems in this regard, however, for now it seems the memory leak issue has been fixed.

21. Kevin (WA) 2011-04-15

    Forgive me, but how are you downloading "the latest build of 1.7.0" ? I only see the latest nightly/continuous build here: http://builds.appcelerator.com.s3.amazonaws.com/index.html">http://builds.appcelerator.com.s3.amazonaws.com/index.html

22. Stephen Tramer 2011-04-15

    You are able to download and build from our github repository: http://github.com/appcelerator/titanium_mobile">http://github.com/appcelerator/titanium_mobile.

23. Kevin (WA) 2011-04-15

    ok, is the github "master" branch considered 1.7.0-continuous at the moment?

24. Stephen Tramer 2011-04-15

    Yes. Master is the latest and should be considered unstable and not generally suitable for release software, unless you absolutely require fixes from it.

25. Thomas Huelbert 2011-05-11 [INFO] Titanium SDK version: 1.7.0 (05/10/11 19:34 879871b...), ipad1 4.2. 3 minutes an a ton of scrolls, not a leak seen using instruments.

JSON Source