Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1441] scrollview memory leak

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionFixed
Resolution Date2011-05-16T11:06:47.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.7.0
ComponentsiOS
Labelsios, klist, memory, rplist, scrollableview
ReporterVitaly Virulaine
AssigneePedro Enrique
Created2011-04-15T02:52:32.000+0000
Updated2011-05-16T11:06:47.000+0000

Description

Hello. I investigated the memory leak issue. I have such code (modified KitchenSink):
var scrollView = Titanium.UI.createScrollableView({

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

});

var dir = Titanium.Filesystem.getFile(Titanium.Filesystem.resourcesDirectory+'/hires');

var files = dir.getDirectoryListing();

for(i=0;i<files.length;i++)
{

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);

}

win.add(scrollView);
So I noticed that every Scroll event free memory decreased by 2-3MB, looks like Titanium creates new view for current focused view and there is NO way to release the memory. I don't understand why memory consumes when I scroll to new view. All views already loaded in that For cycle. I have app crash after 7-8 scrolls on my iPhone 3G. 1.3.0 SDK

Attachments

FileDateSize
archive.zip2011-04-15T02:52:45.000+000015002790
resources-2.zip2011-04-15T02:52:34.000+00007931609

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