Titanium JIRA Archive
Appcelerator Community (AC)

[AC-1733] TiAPI: Changing image property of ImageView causes memory leak

GitHub Issuen/a
TypeBug
Priorityn/a
StatusClosed
ResolutionCannot Reproduce
Resolution Date2013-09-17T22:04:18.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsTitanium SDK & CLI
Labelsandroid, imageView, memory
ReporterJörgen Buder
AssigneeShak Hossain
Created2013-07-24T08:37:20.000+0000
Updated2016-03-08T07:40:37.000+0000

Description

*Problem* We are using a simple window and image view where we every ten seconds change the image property. The object allocates memory every time the image is changed the memory footprint increases until a crash occurs. The app must work on Android and we have verified the problem on both emulator and device. I have also verified the problem with instruments on iOS Simulator where the memory allocations increase over time (hours and days). *Test case* See attached sample. *Steps to reproduce* For Android: 1. Import project 2. Run it in Android, we use OS 4.x. 3. Look at the GC sum in the monitor and observe how it increases 4. Return 1 hour later to see an increase For iOS: In instruments with the iOS simulator, the "alloc" functions increase. *Note* We tried to move the image property setting outside the interval but without luck. We have also tried to set it to null as you can see with the prior imageview object to make sure it cleans up. We also tried to use 16 images (you can too by multiplying the images up to 16.jpg and set the index if statement to 16 so that you give more time for GC, but it does not help).

Attachments

FileDateSize
ImageViewTest.zip2013-07-24T08:37:20.000+00008664056

Comments

  1. Jörgen Buder 2013-08-15

    Daniel, Would it be possible to get some attention to this issue as it now stops our customer to place an order to us. He needs to know this issue is resolved and not leaking memory anymore, please respond, thanks (Also our resource is only here for another week, and for now he does nothing, we need him to work with this customer next week) /Jörgen
  2. Daniel Sefton 2013-08-15

    Ok sure, I will take a look, apologies for the delay.
  3. Daniel Sefton 2013-08-15

    To make sure I'm looking at the same thing -- are you using DDMS and its "Allocation Tracker" tab, and hitting "Start Tracking" then "Get Allocations" after a period of time? Thanks.
  4. Jörgen Buder 2013-08-15

    Hi My goal is to make this work in Android, but the leak can be seen in both platforms, I used Xcode and Instrumentation to verify the same behaviuor there, but yes you should be able to see over time (rather small time if you look hard) that it increases in alloc men, without letting it go. In iOS its fine for long since there are less limitations, but in Android you have from 24 Mb up to about 100 I think, but it eventually crashes. The code you have from me increases and leaks mem in both cases. The code is suppose to run for days and weeks for this product.. Need more info?? Been able to verify the leak? Also please note we have done all kinds of things to let the GC clean up but without results... :(
  5. Jörgen Buder 2013-08-15

    I will keep an eye on this to help you, I can even call you if you need me to...
  6. Jörgen Buder 2013-08-15

    The answer to your question would be yes. ;) And then I keep hitting that button to get new readings..
  7. Daniel Sefton 2013-08-15

    Ok, is it the "Allocation Size" which is increasing for you? And which "Allocation Class" is it? For example: 
    ti.modules.titanium.ui.widget.TiImageView
     
    android.widget.ImageView
     The allocation size of these doesn't appear to be changing. (Just want to be sure about the Android repro before I consider iOS.) Thanks.
  8. Jörgen Buder 2013-08-15

    Hi Daniel I have not yet been able to distinguish from different classes with ddmd/monitor, the only way I can see mem changes is in the total sum of allocated memory, this increases over time, every ten seconds that it changes the image in the image view, I mean we only have the image view here, there are no other UI objects.. Over time the overall mem alloc increases, it should be rather easy to see . .
  9. Jörgen Buder 2013-08-15

    loading it up now for repro . .
  10. Jörgen Buder 2013-08-16

    Hi Daniel Today we tried to sort out the reason why I could not reproduce, as it turns out I earlier had the Titanium Studio 3.1.0, in which I could clearly see increase in object count and allocated memory in the heap in android monitor both on emulator and on device, also we could see this on both old Android SDK and new (4.1.1 I believe). I upgraded to 3.1.1 since the last time I put the JIRA issue and now I could not find it anymore or reproduce, so we did the same thing with my friends account where we today could see the leak everywhere. After upgrade the object count and heap allocation stayed down and so we did not get a crash? Well, unfortunately it seems this was not the source of the real problem (it seldom is right ;) ) so we still have an out of memory in about 250 - 300 image changes, we have some code that reproduces this, however it becomes more complex than this, on a Sony Ericsson Experia S we have a out of memory when allocating memory at about 250 - 300 changes, however on a older Xperia phone we have no problem yet, ans also my HTC one X has no problem and does not give us a out of memory. So now we are confused, let me attach the log cat from the phone on which it crashes, and please take a look at it and give me your opinion on why Android crashers, or is this Android? Or is it Titanium Kroll bridge? Do you know? In any case I would like to know your comment on the log tonight and then lets talk on Skype, thanks.. 08-16 13:26:35.974: I/TiAPI(21173): Showing image with index 4 in imageview 259 08-16 13:26:35.994: E/msm8660.gralloc(21173): Could not mmap handle 0x3e8db0, fd=50 (Out of memory) 08-16 13:26:35.994: W/GraphicBufferMapper(21173): lock(...) failed -12 (Out of memory) 08-16 13:26:35.994: W/Surface(21173): failed locking buffer (handle = 0x3e8db0) 08-16 13:26:36.104: I/DEBUG(154): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 08-16 13:26:36.104: I/DEBUG(154): Build fingerprint: 'SEMC/LT26i_1257-6919/LT26i:2.3.7/6.0.A.3.73/tvP_zw:user/release-keys' 08-16 13:26:36.104: I/DEBUG(154): pid: 21173, tid: 21173 >>> com.purplescout.imageviewtest <<< 08-16 13:26:36.104: I/DEBUG(154): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 08-16 13:26:36.104: I/DEBUG(154): r0 00000000 r1 00000000 r2 00000b40 r3 00000000 08-16 13:26:36.104: I/DEBUG(154): r4 000004fe r5 00000000 r6 00000b80 r7 00000b40 08-16 13:26:36.104: I/DEBUG(154): r8 00000000 r9 7ef0b378 10 6b16fed4 fp 7ef0b318 08-16 13:26:36.104: I/DEBUG(154): ip 00000016 sp 7ef0b1e4 lr 6b170f00 pc 6fd0d058 cpsr 20000010 08-16 13:26:36.104: I/DEBUG(154): d0 0000000000000000 d1 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d2 0000000000000000 d3 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d4 0000001641b00000 d5 44340000442f4000 08-16 13:26:36.104: I/DEBUG(154): d6 41600000442f4000 d7 4080000041500000 08-16 13:26:36.104: I/DEBUG(154): d8 3f80000044340000 d9 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d10 0000000000000000 d11 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d12 0000000000000000 d13 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d14 0000000000000000 d15 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d16 2e2e2e286b636f6c d17 64656c6961662029 08-16 13:26:36.104: I/DEBUG(154): d18 0000000000000000 d19 0000000000000000 08-16 13:26:36.104: I/DEBUG(154): d20 3ff0000000000000 d21 8000000000000000 08-16 13:26:36.104: I/DEBUG(154): d22 0000000000000000 d23 0000000100000001 08-16 13:26:36.104: I/DEBUG(154): d24 38cb4e3338b70e2e d25 38f3ce3d38df8e38 08-16 13:26:36.104: I/DEBUG(154): d26 387a4e1f3865ce1a d27 38a2ce29388e8e24 08-16 13:26:36.104: I/DEBUG(154): d28 38cb400038b70000 d29 3ff0000000000000 08-16 13:26:36.104: I/DEBUG(154): d30 0000000000000000 d31 3ff0000000000000 08-16 13:26:36.104: I/DEBUG(154): scr 20000012 08-16 13:26:36.164: I/DEBUG(154): #00 pc 0000d058 /system/lib/libc.so 08-16 13:26:36.164: I/DEBUG(154): #01 lr 6b170f00 /system/lib/libskia.so 08-16 13:26:36.164: I/DEBUG(154): code around pc: 08-16 13:26:36.164: I/DEBUG(154): 6fd0d038 e3520004 ba00001d e3520010 ba000017 08-16 13:26:36.164: I/DEBUG(154): 6fd0d048 f2202150 e3520080 ba000008 e1a0c3a2 08-16 13:26:36.164: I/DEBUG(154): 6fd0d058 f400028d f400028d f400028d f400028d 08-16 13:26:36.164: I/DEBUG(154): 6fd0d068 e25cc001 1afffff9 e212207f 0a000012 08-16 13:26:36.164: I/DEBUG(154): 6fd0d078 e1b0c2a2 0a000004 e25cc001 f400028d 08-16 13:26:36.164: I/DEBUG(154): code around lr: 08-16 13:26:36.164: I/DEBUG(154): 6b170ee0 e1a07117 e08c5113 e0805005 e1a00005 08-16 13:26:36.164: I/DEBUG(154): 6b170ef0 e2444001 e1a01007 e1a02008 e12fff3a 08-16 13:26:36.164: I/DEBUG(154): 6b170f00 e3740001 e0855006 1afffff7 e1a0000b 08-16 13:26:36.164: I/DEBUG(154): 6b170f10 ebff016b e5dd3148 e3530000 0affffd8 08-16 13:26:36.164: I/DEBUG(154): 6b170f20 eaffffb6 e3a01001 eaffffe1 e3a01000 08-16 13:26:36.164: I/DEBUG(154): stack: 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1a4 00000033 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1a8 003e8dd8 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1ac 4ce05a85 /system/lib/hw/gralloc.msm8660.so 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1b0 003e8db0 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1b4 fffffff4 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1b8 00000033 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1bc 003e8dd8 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1c0 80000001 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1c4 00000030 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1c8 4ce07490 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1cc 4ce05b7f /system/lib/hw/gralloc.msm8660.so 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1d0 003f9420 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1d4 8d76a205 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1d8 df002777 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1dc e3a070ad 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1e0 7ef0b3d4 08-16 13:26:36.164: I/DEBUG(154): #00 7ef0b1e4 00000000 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1e8 00000000 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1ec 000002d0 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1f0 00000500 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1f4 00000000 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1f8 00000000 08-16 13:26:36.164: I/DEBUG(154): 7ef0b1fc 6b131a98 /system/lib/libskia.so 08-16 13:26:36.164: I/DEBUG(154): 7ef0b200 00000500 08-16 13:26:36.164: I/DEBUG(154): 7ef0b204 7ef0b33c 08-16 13:26:36.164: I/DEBUG(154): 7ef0b208 003966d8 08-16 13:26:36.164: I/DEBUG(154): 7ef0b20c 6b132eb4 /system/lib/libskia.so 08-16 13:26:36.164: I/DEBUG(154): 7ef0b210 0039c980 08-16 13:26:36.164: I/DEBUG(154): 7ef0b214 00000033 08-16 13:26:36.164: I/DEBUG(154): 7ef0b218 00396720 08-16 13:26:36.164: I/DEBUG(154): 7ef0b21c 6b91d92b /system/lib/libui.so 08-16 13:26:36.164: I/DEBUG(154): 7ef0b220 7ef0b308 08-16 13:26:36.164: I/DEBUG(154): 7ef0b224 00000000 08-16 13:26:36.164: I/DEBUG(154): 7ef0b228 003965e0
  11. Jörgen Buder 2013-08-16

    by the way we are running tests on smaller images during the weekend so lets talk on monday about this issue and I will give you the results, also we are running on target device to investigate if that system is stable or not, but it will take the weekend to know for sure . .
  12. Shak Hossain 2013-09-17

    Hi Jorgen, I am closing this issue. If you still encounter this bug in our latest CI build of Titanium or 3.1.2, please re-open this. Regards, Shak

JSON Source