{ "id": "86847", "key": "TIMOB-7779", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [ { "id": "12593", "name": "Release 2.0.0", "archived": false, "released": true, "releaseDate": "2012-03-30" }, { "id": "13170", "name": "Sprint 2012-06", "archived": true, "released": true, "releaseDate": "2012-03-25" } ], "resolution": { "id": "1", "description": "A fix for this issue is checked into the tree and tested.", "name": "Fixed" }, "resolutiondate": "2012-07-04T03:38:49.000+0000", "created": "2012-02-22T16:43:30.000+0000", "priority": { "name": "Critical", "id": "1" }, "labels": [ "memory", "qe-and031912", "qe-testadded", "regression", "release-note-2.0.0" ], "versions": [ { "id": "12580", "description": "Dual Runtime 1.8.0", "name": "Release 1.8.0.1", "archived": true, "released": true, "releaseDate": "2011-12-22" }, { "id": "12677", "description": "Release 1.8 Service Pack 1", "name": "Release 1.8.1", "archived": true, "released": true, "releaseDate": "2012-01-31" } ], "issuelinks": [ { "id": "16698", "type": { "id": "10002", "name": "Duplicate", "inward": "is duplicated by", "outward": "duplicates" }, "inwardIssue": { "id": "89552", "key": "TIMOB-8549", "fields": { "summary": "Android: Memory Managment Issue", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "priority": { "name": "High", "id": "2" }, "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false } } } }, { "id": "15502", "type": { "id": "10003", "name": "Relates", "inward": "relates to", "outward": "relates to" }, "outwardIssue": { "id": "86656", "key": "TIMOB-7706", "fields": { "summary": "Android: Evaluate our global reference hack in V8/emulator.", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "priority": { "name": "Medium", "id": "3" }, "issuetype": { "id": "7", "description": "gh.issue.story.desc", "name": "Story", "subtask": false } } } }, { "id": "15817", "type": { "id": "10003", "name": "Relates", "inward": "relates to", "outward": "relates to" }, "inwardIssue": { "id": "88143", "key": "TIMOB-8076", "fields": { "summary": "Android: V8: GC lag can cause crash on older devices", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "priority": { "name": "High", "id": "2" }, "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false } } } } ], "assignee": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2012-07-05T11:29:35.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10202", "name": "Android", "description": "Android Platform" } ], "description": "h2. Problem\r\n\r\n*Note: this issue is only reproducible in an emulator, not a device*\r\n\r\nAfter a set of UI objects is created and then each one is nulled, the resources that they consume are not freed and reused. Hence, the GC process is not working correctly.\r\n\r\nDDMS shows the memory and objects always increasing.\r\n\r\nNote that nulling the objects inside the mainViews() scope should not be necessary. Hence, when the issue affecting the first test case below has been fixed, the second test case should be tested to confirm proper behavior.\r\n\r\nTested and works correclty on the following devices:\r\n* HTC Sensation + HTC Sense 3.0 + Android 2.3.4 + Titanium 2.0.0 (2012/03/01 14:01 0ccdf63) + v8\r\n* Droid 1 (Android 2.2) + Titanium 2.0.0 (2012/02/28) + v8\r\n\r\nh2. Test case\r\n\r\n* run each of the following code, in turn\r\n* click button to create objects\r\n* wait for \"mainViews function has stopped\" before clicking button again\r\n* repeat several times until app crashes\r\n\r\nh3. Test case 1\r\n\r\nWith nulling objects inside mainViews():\r\n\r\n{code:lang=javascript|title=app.js}\r\nvar app = require('testApp');\r\napp.createUI();\r\n{code}\r\n\r\n{code:lang=javascript|title=testApp.js}\r\nvar noOfViews = 50;\r\nvar mainViewsIterations = 0;\r\n\r\nfunction generateViews(noOfViews) {\r\n Ti.API.info('****** mainViews function has started ******');\r\n var views =[];\r\n var view = null;\r\n for (var i=0; i < noOfViews; i++) {\r\n view = Ti.UI.createView();\r\n views.push(view);\r\n }\r\n Ti.API.info('Titanium views created and added to array');\r\n for (var j in views){\r\n views[j] = null;\r\n }\r\n Ti.API.info('Titanium views removed and nulled');\r\n views = null;\r\n Ti.API.info('****** mainViews function has stopped ******');\r\n mainViewsIterations++;\r\n return mainViewsIterations;\r\n}\r\n\r\nexports.createUI = function(){\r\n var win = Ti.UI.createWindow({\r\n backgroundColor: \"white\"\r\n });\r\n\r\n var button = Ti.UI.createButton({\r\n title: 'create ' + noOfViews + ' views'\r\n });\r\n button.addEventListener(\"click\", function(e) {\r\n Ti.API.info('Total views created: ' + generateViews(noOfViews) * noOfViews);\r\n });\r\n\r\n win.add(button);\r\n win.open();\r\n};\r\n{code}\r\n\r\n\r\nh3. Test case 2\r\n\r\nWithout nulling objects inside mainViews():\r\n\r\n{code:lang=javascript|title=app.js}\r\nvar noOfViews = 50;\r\nvar mainViewsIterations = 0;\r\nfunction mainViews(noOfViews) {\r\n\tTi.API.info('****** mainViews function has started ******');\r\n\tvar views =[];\r\n\tvar view = null;\r\n\tfor (var i=0; i < noOfViews; i++) {\r\n\t\tview = Ti.UI.createView();\r\n\t\tviews.push(view);\r\n\t}\r\n\tTi.API.info('Titanium views created and added to array');\r\n\tTi.API.info('****** mainViews function has stopped ******');\r\n\tmainViewsIterations++;\r\n\treturn mainViewsIterations;\r\n}\r\n\r\n\r\nvar win = Ti.UI.createWindow({\r\n\tbackgroundColor: \"white\"\r\n});\r\n\r\nvar button = Ti.UI.createButton({\r\n\ttitle: 'create ' + noOfViews + ' views'\r\n});\r\nbutton.addEventListener(\"click\", function(e) {\r\n\tTi.API.info('Total views created: ' + mainViews(noOfViews) * noOfViews);\r\n});\r\n\r\nwin.add(button);\r\nwin.open();\r\n{code}\r\n\r\nh2. Logs\r\n\r\nTesting with:\r\n* Titanium 2.0.0 (2012/02/21 13:31 5ff41b6)\r\n* Android APIs 2.2\r\n* v8\r\n\r\n{code:lang=none|title=console log for test case 1}\r\n 528 AndroidRuntime D >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<\r\n 528 AndroidRuntime D CheckJNI is ON\r\n 528 AndroidRuntime D --- registering native functions ---\r\n 80 ActivityManager I Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.appcelerator.testing10/.Testing10Activity }\r\n 80 ActivityManager I Start proc com.appcelerator.testing10 for activity com.appcelerator.testing10/.Testing10Activity: pid=534 uid=10036 gids={1015, 3003}\r\n 528 AndroidRuntime D Shutting down VM\r\n 528 AndroidRuntime I NOTE: attach of thread 'Binder Thread #3' failed\r\n 534 TiApplication I (main) [0,0] checkpoint, app created.\r\n 534 TiApplication I (main) [540,540] Titanium 2.0.0 (2012/02/21 13:31 5ff41b6)\r\n 534 TiFastDev D (main) [143,683] Enabling Fastdev on port 42737\r\n 534 TiFastDev D (main) [13,696] sent tokens successfully\r\n 534 TiFastDev D (main) [1,697] Fastdev session handshake succesful.\r\n 534 TiApplication I (main) [12,709] Titanium Javascript runtime: v8\r\n 534 TiRootActivity I (main) [0,0] checkpoint, on root activity create, savedInstanceState: null\r\n 534 TiApplication E (KrollRuntimeThread) [1003,1003] APP PROXY: ti.modules.titanium.app.AppModule@44f695a8\r\n 534 TiAssetHelper D Fetching \"app.js\" with Fastdev...\r\n 534 TiRootActivity I (main) [0,0] checkpoint, on root activity resume. activity = com.appcelerator.testing10.Testing10Activity@44f00240\r\n 80 ActivityManager I Displayed activity com.appcelerator.testing10/.Testing10Activity: 3325 ms (total 3325 ms)\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 TiAPI I Titanium views created and added to array\r\n 534 TiAPI I Titanium views removed and nulled\r\n 534 TiAPI I ****** mainViews function has stopped ******\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 TiAPI I Titanium views created and added to array\r\n 534 TiAPI I Titanium views removed and nulled\r\n 534 TiAPI I ****** mainViews function has stopped ******\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 TiAPI I Titanium views created and added to array\r\n 534 TiAPI I Titanium views removed and nulled\r\n 534 TiAPI I ****** mainViews function has stopped ******\r\n 534 TiAnalyticsSvc W (Thread-12) [28612,28612] Analytics Service Started\r\n 534 TiAnalyticsSvc I (Thread-12) [39,28651] Sending 1 analytics events.\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 TiAnalyticsSvc W (Thread-12) [2103,30754] Stopping Analytics Service\r\n 534 TiAPI I Titanium views created and added to array\r\n 534 TiAPI I Titanium views removed and nulled\r\n 534 TiAPI I ****** mainViews function has stopped ******\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 dalvikvm-heap I Clamp target GC heap from 24.151MB to 24.000MB\r\n 534 TiAPI I Titanium views created and added to array\r\n 534 TiAPI I Titanium views removed and nulled\r\n 534 TiAPI I ****** mainViews function has stopped ******\r\n 534 TiAPI I ****** mainViews function has started ******\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.462MB to 24.000MB\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.833MB to 24.000MB\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.884MB to 24.000MB\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.890MB to 24.000MB\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.891MB to 24.000MB\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.891MB to 24.000MB\r\n 534 dalvikvm-heap I Forcing collection of SoftReferences for 48-byte allocation\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.891MB to 24.000MB\r\n 534 dalvikvm-heap E Out of memory on a 48-byte allocation.\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.891MB to 24.000MB\r\n 534 dalvikvm-heap I Forcing collection of SoftReferences for 136-byte allocation\r\n 534 dalvikvm-heap I Clamp target GC heap from 25.891MB to 24.000MB\r\n 534 dalvikvm-heap E Out of memory on a 136-byte allocation.\r\n 489 DEBUG I *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\r\n 489 DEBUG I Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'\r\n 489 DEBUG I pid: 534, tid: 543 >>> com.appcelerator.testing10 <<<\r\n 489 DEBUG I signal 11 (SIGSEGV), fault addr deadd00d\r\n 489 DEBUG I r0 00000374 r1 0000000c r2 0000000c r3 deadd00d\r\n 489 DEBUG I r4 00000026 r5 80887fc4 r6 00000000 r7 fffe6624\r\n 489 DEBUG I r8 814a0670 r9 47ba1964 10 00265200 fp 45904e60\r\n 489 DEBUG I ip 808881ec sp 47ba1818 lr afd154c5 pc 8083b162 cpsr 20000030\r\n 489 DEBUG I #00 pc 0003b162 /system/lib/libdvm.so\r\n 489 DEBUG I #01 pc 0002cff4 /system/lib/libdvm.so\r\n 489 DEBUG I #02 pc 0002d11a /system/lib/libdvm.so\r\n 489 DEBUG I #03 pc 00035972 /system/lib/libdvm.so\r\n 489 DEBUG I #04 pc 0006a640 /data/data/com.appcelerator.testing10/lib/libkroll-v8.so\r\n 489 DEBUG I #05 pc 0006a6a4 /data/data/com.appcelerator.testing10/lib/libkroll-v8.so\r\n 489 DEBUG I #06 pc 0006a76a /data/data/com.appcelerator.testing10/lib/libkroll-v8.so\r\n 489 DEBUG I #07 pc 0006cd38 /data/data/com.appcelerator.testing10/lib/libkroll-v8.so\r\n 489 DEBUG I \r\n 489 DEBUG I code around pc:\r\n 489 DEBUG I 8083b140 1861447c 200618a2 e878f7d8 f7d82000 \r\n 489 DEBUG I 8083b150 4808e9e4 6bdb5823 d0002b00 4b064798 \r\n 489 DEBUG I 8083b160 701c2426 ea5cf7d8 0004ce80 fffe4ae0 \r\n 489 DEBUG I 8083b170 fffe801c 00000374 deadd00d b510b40e \r\n 489 DEBUG I 8083b180 4c0a4b09 447bb083 aa05591b 6b5bca02 \r\n 489 DEBUG I \r\n 489 DEBUG I code around lr:\r\n 489 DEBUG I afd154a4 b0834a0d 589c447b 26009001 686768a5 \r\n 489 DEBUG I afd154b4 220ce008 2b005eab 1c28d003 47889901 \r\n 489 DEBUG I afd154c4 35544306 d5f43f01 2c006824 b003d1ee \r\n 489 DEBUG I afd154d4 bdf01c30 0002ae7c 000000d4 1c0fb5f0 \r\n 489 DEBUG I afd154e4 43551c3d a904b087 1c16ac01 604d9004 \r\n 489 DEBUG I \r\n 489 DEBUG I stack:\r\n 489 DEBUG I 47ba17d8 00000015 \r\n 489 DEBUG I 47ba17dc afd1453b /system/lib/libc.so\r\n 489 DEBUG I 47ba17e0 afd405a0 /system/lib/libc.so\r\n 489 DEBUG I 47ba17e4 afd4054c /system/lib/libc.so\r\n 489 DEBUG I 47ba17e8 00000000 \r\n 489 DEBUG I 47ba17ec afd154c5 /system/lib/libc.so\r\n 489 DEBUG I 47ba17f0 00237cc0 [heap]\r\n 489 DEBUG I 47ba17f4 afd1450d /system/lib/libc.so\r\n 489 DEBUG I 47ba17f8 fffe6624 \r\n 489 DEBUG I 47ba17fc 80887fc4 /system/lib/libdvm.so\r\n 489 DEBUG I 47ba1800 80887fc4 /system/lib/libdvm.so\r\n 489 DEBUG I 47ba1804 00000000 \r\n 489 DEBUG I 47ba1808 fffe6624 \r\n 489 DEBUG I 47ba180c afd1456b /system/lib/libc.so\r\n 489 DEBUG I 47ba1810 df002777 \r\n 489 DEBUG I 47ba1814 e3a070ad \r\n 489 DEBUG I #00 47ba1818 00000001 \r\n 489 DEBUG I 47ba181c 8082cff9 /system/lib/libdvm.so\r\n 489 DEBUG I #01 47ba1820 00000001 \r\n 489 DEBUG I 47ba1824 8082d11f /system/lib/libdvm.so\r\n 33 Zygote D Process 534 terminated by signal (11)\r\n 80 ActivityManager I Process com.appcelerator.testing10 (pid 534) has died.\r\n 80 WindowManager I WIN DEATH: Window{451f0f80 com.appcelerator.testing10/com.appcelerator.testing10.Testing10Activity paused=false}\r\n 80 UsageStats I Unexpected resume of com.android.launcher while already resumed in com.appcelerator.testing10\r\n 80 InputManagerService W Got RemoteException sending setActive(false) notification to pid 534 uid 10036\r\n{code}\r\n\r\nh2. Discussions\r\n\r\nQ&A Post: [http://developer.appcelerator.com/question/132357/memory-leaks-on-android-but-not-on-ios---very-simple-test-case]\r\n\r\nh2. Workaround\r\n\r\nUntil this issue is resolved, the recommendation is to use the Rhino Javascript runtime, which can be enabled by editing the tiapp.xml file (open using the Titanium Studio, to use its visual editor)", "attachment": [ { "id": "26341", "filename": "android 2.2 emu sdk 2.0.0.txt", "author": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-19T17:06:10.000+0000", "size": 17896, "mimeType": "text/plain" }, { "id": "26342", "filename": "android 2.3.3 emu sdk 2.0.0 crash.txt", "author": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-19T17:06:10.000+0000", "size": 18143, "mimeType": "text/plain" } ], "flagged": false, "summary": "Android: V8: Proxy memory leak on emulator.", "creator": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "subtasks": [], "reporter": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "environment": "* Ti SDK 1.8.0.1, 1.8.1 and 1.9.v20120209110134, 2.0.0 (2012/03/01 14:01 0ccdf63)\r\n* Android 2.2, 2.3.3, 4.0 (3.0 seems to be OK)\r\n* Runtime: V8\r\n* Emulator only", "comment": { "comments": [ { "id": "184014", "author": { "name": "ngupta", "key": "ngupta", "displayName": "Neeraj Gupta", "active": true, "timeZone": "America/Los_Angeles" }, "body": "It seems that the garbage collector is not kicking in if we are creating a large number of views (5000 in this case) in a tight loop.", "updateAuthor": { "name": "ngupta", "key": "ngupta", "displayName": "Neeraj Gupta", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-02-22T16:47:13.000+0000", "updated": "2012-02-22T16:47:13.000+0000" }, { "id": "184035", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Is there any technical explanation why variables needs to (or must) be nullified?\r\n\r\n\r\nIn test case above, in \"mainViews\" function all variables are local variables, therefore, they should be automatically GC when that function finishes with execution. ", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-02-23T02:27:48.000+0000", "updated": "2012-02-23T02:27:48.000+0000" }, { "id": "184044", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Just to add one more thing. IMHO, setting variable to \"null\" could have sense in cases when circular reference is present (which GC misses to detect). Something like this:\r\n\r\n{code}\r\n(function() {\r\n\t\r\n\tvar win = Ti.UI.createWindow({\r\n\t\tbackgroundColor: '#000'\r\n\t});\r\n\t\r\n\tvar button = Ti.UI.createButton({\r\n\t\ttitle: 'Create circular reference'\r\n\t});\r\n\t\r\n\tbutton.addEventListener('click', function() {\r\n\t\t\r\n\t var win1 = Ti.UI.createWindow({\r\n\t \tbackgroundColor: '#369'\r\n\t });\r\n\t \r\n\t\tvar button1 = Ti.UI.createButton({\r\n\t\t\ttitle: 'Close'\r\n\t\t});\r\n\t\t\r\n\t\tbutton1.addEventListener('click', function() {\r\n\t\t\t//win1 -> button1 -> \"click\" event listener -> win1\r\n\t\t win1.close();\r\n\t\t Ti.API.info('Available memory: ' + Ti.Platform.availableMemory);\r\n\t\t});\r\n\t\t\r\n\t\twin1.add(button1);\r\n\t\t\r\n\t\twin1.open();\r\n\t});\r\n\t\r\n\twin.add(button);\r\n\t\r\n\twin.open();\r\n\t\r\n})();\r\n{code}\r\n\r\nSetting \"win1\" to \"null\" after calling \"close\" in this case have sense.\r\n\r\nI tried to run this example and memory seems to stay constant. Am I missing something? :)\r\n\r\n\r\nAre there more memory leak patterns?", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-02-23T06:04:35.000+0000", "updated": "2012-02-23T06:04:35.000+0000" }, { "id": "184047", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Thanks Ivan - I was just being thorough. ;) However, I have updated the ticket to clarify the observations.", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-02-23T06:52:26.000+0000", "updated": "2012-02-23T06:52:26.000+0000" }, { "id": "184761", "author": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "body": "We have done some testing with the latest build of titanium (2.0.0.v20120301000143) and found the same memory leak problem in rhino as well, so I don't think your workaround is valid.", "updateAuthor": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-01T06:45:00.000+0000", "updated": "2012-03-01T06:45:00.000+0000" }, { "id": "184869", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Athanasios - I've deduced that this is an emulator issue, and hence works as expected on a device.\r\n\r\nNote that this is a v8 issue (see title). If you have a problem with Rhino, that you are able to prove, please raise another ticket.\r\n\r\nThanks", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-02T04:30:31.000+0000", "updated": "2012-03-02T04:30:31.000+0000" }, { "id": "184871", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "As I said on Q/A topic, I can reproduce this issue on device (Thinkpad tablet, Android 3.1). It seems that adding view to a window makes the difference. Here is my test case:\r\n\r\n\r\n{code}\r\nfunction mainViews() {\r\n \r\n var newWin = Ti.UI.createWindow({ navBarHidden: true });\r\n \r\n Ti.API.info('****** mainViews function has started ******');\r\n var views =[];\r\n var view = null;\r\n for (var i=0; i < 1000; i++) {\r\n view = Ti.UI.createView();\r\n views.push(view);\r\n newWin.add(view);\r\n }\r\n \r\n \r\n newWin.open();\r\n \r\n \r\n Ti.API.info('Titanium views created and added to array');\r\n Ti.API.info('****** mainViews function has stopped ******');\r\n}\r\n\r\nvar win = Ti.UI.createWindow({\r\n backgroundColor: \"white\"\r\n});\r\n\r\nvar button = Ti.UI.createButton({\r\n title: \"create 5k views\"\r\n});\r\nbutton.addEventListener(\"click\", function(e) {\r\n mainViews();\r\n Ti.API.info('Available memory: ' + Ti.Platform.availableMemory);\r\n});\r\n\r\nwin.add(button);\r\nwin.open();\r\n{code}\r\n\r\n\r\nIf \"newWin\" code is commented out, memory is not freed.", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-02T04:47:16.000+0000", "updated": "2012-03-02T04:47:16.000+0000" }, { "id": "184872", "author": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Paul,\r\n\r\nI've seen the title (I am not blind...) and I know that this issue concerns V8.\r\n\r\nThe reason I mentioned Rhino is your Workaround Recommendation to use the Rhino Javascript runtime!\r\n\r\nThanks", "updateAuthor": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T04:47:54.000+0000", "updated": "2012-03-02T04:47:54.000+0000" }, { "id": "184873", "author": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "body": "I confirm Ivan's test case.\r\n\r\nIt seems that adding view to a window makes the difference!!!", "updateAuthor": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T04:50:54.000+0000", "updated": "2012-03-02T04:50:54.000+0000" }, { "id": "184885", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Guys,\r\n\r\nI have just completed testing Ivan's code on my Android phone (2.3.4) and the emulator - the app never releases memory and I can make it crash after about 10 clicks every time. I left the newWin.Open() un-commented and click the 5k button and back button at an easy pace to give the OS time to garbage collect and it crashes.\r\n\r\nPauls Test case: was ROOT Window and add 1000 views to it\r\n\r\nIvan Test case: was ROOT Window with button to create 5000 views add those views to a New window and then close the window to release the memory\r\n\r\nI can confirm both test cases still crashes on emulator and phone using SDK 1.8.1 to test using V8. \r\n\r\nIvan's test case is no different than the Memory Pool\" work around that has been floating around on the Q/A blog. His test case also breaks Appceraltors own recommendation of using \"Single Context\" (ie single window for entire application). It also doesnt follow the rule of Nulling variables will mark it for garbage collection to eventually be released.\r\n\r\nThank You \r\n\r\n\r\n", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T08:45:38.000+0000", "updated": "2012-03-02T08:45:38.000+0000" }, { "id": "184888", "author": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "body": "This may be caused by our global reference hack we use on emulator. It may have some bugs and isn't working properly. I have opened TIMOB-7706 to re-evaluate it.", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T09:48:25.000+0000", "updated": "2012-03-02T09:48:25.000+0000" }, { "id": "184889", "author": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Although this issue concerns V8, I can confirm that Ivan's test case crashes on emulator using both V8 and Rhino (continuous builds - version 2.0.0.v20120301000143). \r\n\r\nMathew, could you please confirm that Ivan's code crashes on your device using Rhino as well?\r\nThank you in advance.\r\n\r\nPS. I repeat once again that the reason I mention Rhino - although this is a V8 issue/ticket - is the Workaround Recommendation to use the Rhino Javascript runtime!", "updateAuthor": { "name": "anikolaou@greekgeeks.com", "key": "anikolaou@greekgeeks.com", "displayName": "Athanasios Nikolaou", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T10:08:59.000+0000", "updated": "2012-03-02T10:08:59.000+0000" }, { "id": "184905", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Will this also resolve memory leaks on the phone as well?\r\n\r\nThanks", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T12:06:18.000+0000", "updated": "2012-03-02T12:06:18.000+0000" }, { "id": "184923", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "As per Paul's request.\r\n\r\nUsed Test Case 1 from above. Crashes on Android Phones after 10 or so clicks.\r\nSDK: 2.0.0.v20120302121644\r\nStudio: 1.0.8.201201262211\r\nAndroid Runtime: V8\r\n\r\nAdroid Device: HTC Verizon Thunderbolt\r\nOS Version: 2.3.4\r\nModel: ADR6500l\r\n\r\nAndroid Device: HTC T-mobile G2\r\nOS Version: 2.3.4\r\nModel: T-Mobile G2\r\n\r\nIs there any other information I can provide. I have testes this on 2 other devices as well.\r\n\r\nThank You\r\n\r\n\r\n\r\n", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T14:02:44.000+0000", "updated": "2012-03-02T14:02:44.000+0000" }, { "id": "184926", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Mathew, out of interest, are you clicking the button in quick succession, or are you waiting for the underlying code to fully complete before pressing again?", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-02T14:12:14.000+0000", "updated": "2012-03-02T14:12:14.000+0000" }, { "id": "184930", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "I am waiting a few seconds before each click allowing the code to complete.", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-02T14:36:54.000+0000", "updated": "2012-03-02T14:36:54.000+0000" }, { "id": "185135", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Moved code for test case 1 into a commonJS module, to be certain of not polluting the global scope. However, it's not pretty - do not write commonjs modules that look like this! ;)\r\n\r\nThe results in the emulator are the same as reported before.", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-06T03:44:02.000+0000", "updated": "2012-03-06T03:45:02.000+0000" }, { "id": "185136", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Global scope would be polluted in case when variable is declared without \"var\" keyword. That is not the case here and view variables are local variables in function scope.", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-06T04:12:52.000+0000", "updated": "2012-03-06T04:12:52.000+0000" }, { "id": "185151", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "I have tested Seans new test case from his post and get the same results. ", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T07:51:13.000+0000", "updated": "2012-03-06T07:52:56.000+0000" }, { "id": "185155", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Guys,\r\n\r\nI am getting the same results as Mathew using test case 1 from above. I have tested this on 2 Android phones running 2.3.4. The phone crashes after about 10 - 15 clicks. I also waited a little bit between each click to make sure everything was done running before clicking again.\r\n\r\nModel: HTC EVO 4g\r\nOS: 2.3.4\r\n\r\nModel: T-Mobile G2\r\nOS: 2.3.4\r\n\r\n\r\nYesterday I posted another test case because its had been mentioned in a few previous post that this is not \"Real World\". The test case I send yesterday should be a pretty common real world example. This sample also crashes after toggling back and forth between the 2 views.\r\n\r\nHope this may help prove that there is an issue with memory and V8\r\n\r\nThank You", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T09:17:44.000+0000", "updated": "2012-03-06T09:17:44.000+0000" }, { "id": "185156", "author": { "name": "ngupta", "key": "ngupta", "displayName": "Neeraj Gupta", "active": true, "timeZone": "America/Los_Angeles" }, "body": "@Mathew, @Sean - Please confirm that you are using the 1.8.2 GA release because we had fixed a number of memory leaks in this release.", "updateAuthor": { "name": "ngupta", "key": "ngupta", "displayName": "Neeraj Gupta", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T09:26:36.000+0000", "updated": "2012-03-06T09:26:36.000+0000" }, { "id": "185220", "author": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "body": "A report on my findings so far...\r\n\r\nFor the two test cases in the description I am only\r\nable to produce the leak on emulator. Unable to reproduce against\r\nlatest master build on Xoom (4.0.3), HTC Desire (2.2), and HTC Evo 4g (2.3.5).\r\nI believe this is related to the difference in how we manage JNI references on emulator.\r\nBy disabling this different branch in the code the leak no longer occurred on the emulator.\r\n\r\nFor Ivan's test case by opening a new window with a large view count. I am able to reproduce\r\nthis on device and appears to be a bug related to how we clean up windows once they close.\r\nIvan if you could file a new issue for this since it appears unrelated to the one seen on emulator\r\nfor test cases 1 & 2.\r\n\r\nIf anyone can still produce an out of memory crash using the two test cases in the description\r\non device using a recent CI build (master branch) please report back with device information.\r\n", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T13:35:00.000+0000", "updated": "2012-03-06T13:35:27.000+0000" }, { "id": "185226", "author": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Ivan,\r\n\r\nI went ahead of filed a ticket for the bug your test case creates.\r\nPlease direct your attention to TIMOB-7897. Thanks.", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T13:52:08.000+0000", "updated": "2012-03-06T13:52:08.000+0000" }, { "id": "185239", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Josh, Neeraj & Paul,\r\n\r\nAs mentioned in the Problem Description:\r\n Tested and works correclty on the following devices:\r\n HTC Sensation + HTC Sense 3.0 + Android 2.3.4 + Titanium 2.0.0 (2012/03/01 14:01 0ccdf63) + v8\r\n\r\nI am able to reproduce this issue on all of my Android Devices every single time I run both of the above test cases. This is NOT just an issue on the emulator. I believe Mathew has confirmed this earlier as well with his Android Devices. \r\n\r\nIs there a specific build that I need to use to verify your test results?\r\n\r\nIt appears from the post above that you are using SDK 2.0 built on March 1st 2012. I am the March 2nd build (2.0.0.v20120302121644) with Studio build: 1.0.8.201201262211.\r\n\r\nI have just verified this again on my T-Mobile G2, HTC Thunderbolt so far and it still crashes after 10 or so clicks and waiting between each click.\r\n\r\nMathew can you comment on the above and verify your results?\r\n\r\nThank You\r\n\r\n ", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T14:28:39.000+0000", "updated": "2012-03-06T14:30:56.000+0000" }, { "id": "185241", "author": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Sean,\r\n\r\nCould you verify again with a new project (just to make sure there is no stale build issues)\r\nand use the most recent CI build (March 6th, Master branch). If you can supply a log out of crash\r\nas well this may provide clues as well.\r\n\r\nThanks for your help, hopefully we can get to the bottom of the issue.\r\n", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-06T14:49:21.000+0000", "updated": "2012-03-06T14:49:32.000+0000" }, { "id": "185302", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Josh,\r\n\r\n\r\nI actually don't have memory issues with test case I provided. I suspected that window closing somehow triggers GC because in the app I'm developing, there are about 1000 components in one window (one form) and app would crash soon if memory would not be releasing.", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-07T00:31:43.000+0000", "updated": "2012-03-07T00:59:44.000+0000" }, { "id": "185333", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Josh,\r\n\r\nI will try that here shortly. Is there any way to create/capture the crash log on the Android device?\r\n\r\nIvan:\r\n\r\nMy and Pauls test case is not related to opening and closing windows. It is simply only to do with not releasing resources within a view when objects are set to null in that view. This is the issue that I am trying to resolve because I only open 1 root window followed by multiple views inside that window to navigate between pages/menu options. No matter what you put on the view (eg:labels, buttons, tablerows, etc) and null them - memory keeps growing and crashes the app on both the emulator and android device.\r\n\r\nI realize there is an issue with the emulator, my most pressing issue is getting this resolved on the Android device.\r\n\r\nThanks", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-07T07:26:43.000+0000", "updated": "2012-03-07T07:26:43.000+0000" }, { "id": "185368", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Guys,\r\n\r\nHere is the part of log that shows Pauls test case 1 crash due to memory on my Android Phone running 2.3.4. I have the full log file, is there some place I could post the log to or email it to you guys directly if needed. \r\n\r\n{code:none}\r\n*********************Part of Log File*****************************\r\nI/dalvikvm-heap(14048): Clamp target GC heap from 33.953MB to 32.000MB\r\n\r\nD/dalvikvm(14048): GC_FOR_MALLOC freed 0K, 9% free 27174K/29703K, external 3125K/4625K, paused 370ms\r\n\r\nE/dalvikvm-heap(14048): Out of memory on a 80-byte allocation.\r\n\r\nI/dalvikvm(14048): Can't dump thread 10: threadObj not set\r\n\r\nE/dalvikvm(14048): Out of memory: Heap Size=29703KB, Allocated=27174KB, Bitmap Size=3125KB, Limit=32768KB\r\n\r\nE/dalvikvm(14048): Extra info: Footprint=29703KB, Allowed Footprint=29703KB, Trimmed=592KB\r\n\r\nI/dalvikvm-heap(14048): Clamp target GC heap from 33.953MB to 32.000MB\r\n\r\nD/dalvikvm(14048): GC_FOR_MALLOC freed 0K, 9% free 27174K/29703K, external 3125K/4625K, paused 359ms\r\n\r\nI/dalvikvm-heap(14048): Forcing collection of SoftReferences for 280-byte allocation\r\n\r\nI/dalvikvm-heap(14048): Clamp target GC heap from 33.953MB to 32.000MB\r\n\r\nD/dalvikvm(14048): GC_FOR_MALLOC freed 0K, 9% free 27174K/29703K, external 3125K/4625K, paused 316ms\r\n\r\nE/dalvikvm-heap(14048): Out of memory on a 280-byte allocation.\r\n\r\nI/dalvikvm(14048): \"KrollRuntimeThread\" prio=5 tid=8 RUNNABLE\r\n\r\nI/dalvikvm(14048): | group=\"main\" sCount=0 dsCount=0 obj=0x4059f3f0 self=0x2cb898\r\n\r\nI/dalvikvm(14048): | sysTid=14055 nice=0 sched=0/0 cgrp=default handle=2944320\r\n\r\nI/dalvikvm(14048): | schedstat=( 42817810102 13039886438 37121 )\r\n\r\nI/dalvikvm(14048): at java.lang.Class.newInstanceImpl(Native Method)\r\n\r\nI/dalvikvm(14048): at java.lang.Class.newInstance(Class.java:1409)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.KrollProxy.createProxy(KrollProxy.java:116)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.runtime.v8.V8Object.nativeFireEvent(Native Method)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.runtime.v8.V8Object.fireEvent(V8Object.java:47)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.KrollProxy.doFireEvent(KrollProxy.java:441)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.KrollProxy.handleMessage(KrollProxy.java:602)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.titanium.proxy.TiViewProxy.handleMessage(TiViewProxy.java:347)\r\n\r\nI/dalvikvm(14048): at android.os.Handler.dispatchMessage(Handler.java:95)\r\n\r\nI/dalvikvm(14048): at android.os.Looper.loop(Looper.java:130)\r\n\r\nI/dalvikvm(14048): at org.appcelerator.kroll.KrollRuntime$KrollRuntimeThread.run(KrollRuntime.java:102)\r\n\r\nI/dalvikvm(14048): \r\n\r\nE/dalvikvm(14048): Out of memory: Heap Size=29703KB, Allocated=27174KB, Bitmap Size=3125KB, Limit=32768KB\r\n\r\nE/dalvikvm(14048): Extra info: Footprint=29703KB, Allowed Footprint=29703KB, Trimmed=592KB\r\n\r\nI/dalvikvm-heap(14048): Clamp target GC heap from 33.953MB to 32.000MB\r\n\r\nD/dalvikvm(14048): GC_FOR_MALLOC freed 0K, 9% free 27174K/29703K, external 3125K/4625K, paused 316ms\r\n\r\nI/dalvikvm-heap(14048): Forcing collection of SoftReferences for 280-byte allocation\r\n\r\nI/Kineto::main( 1400): WCMGetLinkMetricsCbk iRSSI:-54\r\n\r\nE/KINETO ( 1400): KLOG004- IPA_LinkMetric: -54 -53 0 18 0 0x00\r\n\r\nE/KINETO ( 1400): KLOG0B4- IPA_ZoneMetric: 8 8 -53 -75 -85 1 0x001 0 0\r\n\r\nI/dalvikvm-heap(14048): Clamp target GC heap from 33.953MB to 32.000MB\r\n\r\nD/dalvikvm(14048): GC_FOR_MALLOC freed 0K, 9% free 27174K/29703K, external 3125K/4625K, paused 363ms\r\n\r\nE/dalvikvm-heap(14048): Out of memory on a 280-byte allocation.\r\n\r\nI/dalvikvm(14048): \"main\" prio=5 tid=1 RUNNABLE\r\n\r\nI/dalvikvm(14048): | group=\"main\" sCount=0 dsCount=0 obj=0x40027198 self=0xce60\r\n\r\nI/dalvikvm(14048): | sysTid=14048 nice=0 sched=0/0 cgrp=default handle=-1345006528\r\n\r\nI/dalvikvm(14048): | schedstat=( 9586303718 1874511713 2793 )\r\n\r\nI/dalvikvm(14048): at android.view.MotionEvent.obtain(MotionEvent.java:~383)\r\n\r\nI/dalvikvm(14048): at android.os.MessageQueue.nativePollOnce(Native Method)\r\n\r\nI/dalvikvm(14048): at android.os.MessageQueue.next(MessageQueue.java:119)\r\n\r\nI/dalvikvm(14048): at android.os.Looper.loop(Looper.java:117)\r\n\r\nI/dalvikvm(14048): at android.app.ActivityThread.main(ActivityThread.java:3683)\r\n\r\nI/dalvikvm(14048): at java.lang.reflect.Method.invokeNative(Native Method)\r\n\r\nI/dalvikvm(14048): at java.lang.reflect.Method.invoke(Method.java:507)\r\n\r\nI/dalvikvm(14048): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)\r\n\r\nI/dalvikvm(14048): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)\r\n\r\nI/dalvikvm(14048): at dalvik.system.NativeStart.main(Native Method)\r\n\r\nI/dalvikvm(14048): \r\n\r\nE/dalvikvm(14048): Out of memory: Heap Size=29703KB, Allocated=27174KB, Bitmap Size=3125KB, Limit=32768KB\r\n\r\nE/dalvikvm(14048): Extra info: Footprint=29703KB, Allowed Footprint=29703KB, Trimmed=592KB\r\n\r\nI/Process ( 1296): Sending signal. PID: 14048 SIG: 9\r\n\r\nW/ActivityManager( 1296): Force finishing activity com.appdesigngeeks.paulDTest/.PauldtestActivity\r\n\r\n***************************************************\r\n{code}\r\n\r\nI have reproduce the same crash on multiple Android devices.\r\n\r\nThanks for any help ", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-07T10:45:18.000+0000", "updated": "2012-03-07T10:49:25.000+0000" }, { "id": "185476", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Guys,\r\n\r\nI have noticed that Pauls test case has changed a couple of times since this ticket was created. Just to confirm what is the code that I should be using? I see the post that Paul references test case 1 on the following:\r\n\r\nPaul Dowsett added a comment - 06/Mar/12 3:44 AM - edited\r\nMoved code for test case 1 into a commonJS module, to be certain of not polluting the global scope. However, it's not pretty - do not write commonjs modules that look like this! \r\n\r\nBut as stated above you would write code like this!! This seems to be causing confusion between everyone who is trying to test this on Android device and verify the results. Can you guys confirm the code that Mathew and myself should be testing?\r\n\r\nIs someone going to change the title of the ticket back to include Android device and not just the emulator until it is proven fixed?\r\n\r\nThank You", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-07T23:49:25.000+0000", "updated": "2012-03-07T23:49:25.000+0000" }, { "id": "185478", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "To stop this nullifying-paraonia :D\r\n\r\n\r\nFirst, you need to differentiate: value and value's reference. When doing this:\r\n\r\n{code}\r\nvar a = 1;\r\n{code}\r\n\r\ntwo things are done: value \"1\" is created and a reference is added to it, which is \"a\" variable.\r\n\r\n\r\nWhen doing this:\r\n\r\n{code}\r\nvar b = a;\r\n{code}\r\n\r\nonly one thing is done, that is, one more reference to value \"1\" is created. So, now there are two references to the same value. \r\n\r\n\r\n\r\n\r\nHere is the catch: by doing this:\r\n\r\n{code}\r\na = null;\r\n{code}\r\n\r\n\r\nyou are not destroying value \"1\", you have just referenced to different value. Garbage collection counts value references, where there are no more references to some value, it can be released. So, if you do this:\r\n\r\n{code}\r\nb = null;\r\n{code}\r\n\r\nyou just reference other thing. Now, nothing references value \"1\" and therefore that memory space can be released. When it will be removed it is not up to you, but to GC mechanism.\r\n\r\n\r\n\r\nIn particular case above, all view variables are local variables in function scope and they will be destroyed when function finishes with execution. References that they contain will be destroyed, nullifying them has no sense and if it is necessary, then something is terribly wrong. :)\r\n\r\n\r\n\r\nSetting variable to null could have sense in some cases, as I mentioned in one comment.", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-08T00:31:14.000+0000", "updated": "2012-03-08T00:38:09.000+0000" }, { "id": "185479", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Ivan,\r\n\r\nThe nullifing paranoia comes from the fact that Appcelerator Recommends this as best practice in their own guides :>. Nulling something is the only way in Titanium to indicate that an object is no longer needed because there is no free method only remove method.\r\n\r\nI agree that all local variable in a function SHOULD be destroyed once the function is done executing but this is not the case. I feel like Mathews and my test cases have shown this over and over again that something is not working correctly.\r\n\r\nIn none of my test cases or real world apps have I created any circular reference with objects and I have been more than careful to make sure that objects are created and destroyed in the correct order.\r\n\r\nDo you have a \"Hello World\" test case that will create and destroy objects that can show that there are no memory leak issues with V8 on Android device? Just to make sure this test case should not include opening and closing windows as the solution.\r\n\r\nThank You\r\n", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T01:16:19.000+0000", "updated": "2012-03-08T01:16:19.000+0000" }, { "id": "185480", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Yeah, they recommend that and people are paranoid and mislead because of that. Even some of their employees think that nullifying a variable destroys a value it references. Anyway, nobody knows everything (I also might have missed some technical reason they have for that, but I am pretty sure that things functions this way in other environments) and I hope explanation of variable nullifying will be more precise and comprehensive.\r\n\r\n\r\n\r\nThere is my test case above and I am not experiencing memory issues on device that I use.", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-08T02:34:47.000+0000", "updated": "2012-03-08T02:34:47.000+0000" }, { "id": "185484", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Ivan,\r\n\r\nNullifying objects actually does destroy objects that they reference. My test case works perfect on iOS and if you run instruments you can see the difference between nullifying objects and not nullifying them. My sample App uses a single root window and opening views and removing them and nullifying all of the UI objects works PERFECT on iOS and not even close on Android. Thats the whole point with this ticket.\r\n\r\nOnce again your above example opens another window other than your root window. And you say your self that if you remove the win.open that the objects never get destroyed. You should be able to destroy object and have them GC'd correctly just by running the function again or nullifying the variables. Openning a window should have NOTHING to do with Garbage Collection. \r\n\r\nAm I missing something with the win.open ???\r\n\r\nThanks", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T02:47:36.000+0000", "updated": "2012-03-08T02:47:36.000+0000" }, { "id": "185493", "author": { "name": "skypanther", "key": "skypanther", "displayName": "Tim Poulsen", "active": true, "timeZone": "America/New_York" }, "body": "Ivan, I wrote the bit in our guides about nulling objects. And I agree, it should be a little more clear that setting a variable to null isn't a requirement for marking an object ready for GC. But for developers who aren't skilled JavaScript programmers, the recommendation can be useful. It's easy to unintentionally create a closure, leave a reference hanging in a global event listener, hoist some variable into the global namespace, etc. I'd hazard a guess that many (most?) of our developers aren't using either the require() modular pattern or the function-wrapped technique meaning they aren't getting any object reference clean up for free. Anyway, I'll make a note to revisit that guide.", "updateAuthor": { "name": "skypanther", "key": "skypanther", "displayName": "Tim Poulsen", "active": true, "timeZone": "America/New_York" }, "created": "2012-03-08T05:24:07.000+0000", "updated": "2012-03-08T05:24:07.000+0000" }, { "id": "185497", "author": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "@Sean - You missed to understand that part. I said that I suspected that Titanium's internal GC mechanism is triggered by window closing, or have affect on it (but in any case, window in test case should not have affect on views GC).\r\n\r\n\r\n\r\n@Tim - Yeah, I agree with you that in some cases that can be helpful. But still, precise explanation is, IMO, needed because otherwise developers are pushed into wrong direction - they will still have bad JS habits and beside that, they will wrongly think that they destroy values by setting variable to null. Setting variable to null is not solution in any case. Good JS practice might be. :)\r\nAnyway, one more thing to revise is Titanium's event system. I think it is the source of many bad habits. Something to think about in the future. ;)", "updateAuthor": { "name": "ivan.skugor", "key": "ivan.skugor", "displayName": "Ivan Skugor", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2012-03-08T06:03:52.000+0000", "updated": "2012-03-08T06:03:52.000+0000" }, { "id": "185526", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Tim & Ivan,\r\n\r\nI agree that creating variables inside of functions should \"clean\" up the reference to them when the function is done executing and without having to set them null should work. \r\n\r\nI am also wondering why the Javascript samples that Sean and I have created work correctly in iOS and the same exact code does not clean up at all in Android.\r\n\r\nLike Sean said above can either of you guys provide a sample code that does not involve opening a window as the work around for triggering garbage collection?\r\n\r\nCan someone provide sample code / test case that will work in both iOS and Android and show exactly how one should go about structuring and cleaning up views - ie using self-calling closure functions or using CommonJS module with exports that works correctly with the latest build of the SDK.\r\n\r\nI will run Ivan's test code from above again with the latest build (March 8th) and post my results.\r\n\r\nThank you\r\n", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T09:13:11.000+0000", "updated": "2012-03-08T09:13:11.000+0000" }, { "id": "185528", "author": { "name": "jhaynie", "key": "jhaynie", "displayName": "Jeff Haynie", "active": false, "timeZone": "America/Los_Angeles" }, "body": "If variables inside a function don't get released after the function scope is destroyed (assuming declared with var) -- this is a bug still.", "updateAuthor": { "name": "jhaynie", "key": "jhaynie", "displayName": "Jeff Haynie", "active": false, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T09:16:30.000+0000", "updated": "2012-03-08T09:16:30.000+0000" }, { "id": "185538", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Jeff,\r\n\r\nThanks for your feedback - appreciate your input. Can you or someone at Appcelerator please clarify with a simple example - which of the following methods you are referring to in your comment above?\r\n\r\n1. Assigning a function to a variable and setting the variable to null?\r\n\r\n2. Declaring local variables within a function - once the function has completed all local variables within the function will be automatically destroyed with out setting them to null?\r\n\r\nThanks", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T09:49:37.000+0000", "updated": "2012-03-08T09:49:37.000+0000" }, { "id": "185560", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Jeff and Mathew,\r\n\r\nHere is a simple test case that works perfect with iOS and crashes due to memory on Android. The section of code that creates the labels is in a function which by definition should be released after the function is done execution. Using Instruments you can see the object count jump and then get released after a short period of time. If you run the same exact code on Android memory continues to grow until the app eventually crashes.\r\n\r\nIs there something in the code that needs to be changed to get this to work on Android device?\r\n\r\n{code:none}\r\nvar win = Ti.UI.createWindow({\r\n backgroundColor: \"white\"\r\n});\r\n//create View 1 - yellow background\r\nvar button = Ti.UI.createButton({\r\n title: \"Go To View 1\"\r\n});\r\nbutton.addEventListener(\"click\", function(e) {\r\n view1New();\r\n}); \r\n//add button to window\r\nwin.add(button);\r\n//open Main window\r\nwin.open();\r\n \r\nfunction view1New(){\r\n \r\n //create view 1\r\n var view1 = Ti.UI.createView({\r\n backgroundColor: 'yellow',\r\n });\r\n \r\n //function to create labels on each of the 2 views\r\n var mainLabelsFunction1 = function mainLabels() {\r\n Ti.API.info('****** mainLabels function has started ******');\r\n var labels =[];\r\n var label = null;\r\n for (var i=0; i < 2000; i++) {\r\n label = Ti.UI.createLabel();\r\n labels.push(labels);\r\n }\r\n Ti.API.info('Titanium labels created and added to array');\r\n Ti.API.info('****** mainLabels function has stopped ******');\r\n \r\n }\r\n //create Labels\r\n mainLabelsFunction1();\r\n mainLabelsFunction1 = null;\r\n \r\n \r\n \r\n var buttonView1 = Ti.UI.createButton({\r\n title: \"Go To View 2\"\r\n });\r\n buttonView1.addEventListener(\"click\", function(e) {\r\n view2New(); \r\n Ti.API.info('****** Clean Up of View 1 ******'); \r\n //clean up View 1\r\n \r\n \r\n view1.remove(buttonView1);\r\n buttonView1 = null;\r\n win.remove(view1);\r\n view1 = null;\r\n }); \r\n view1.add(buttonView1);\r\n win.add(view1);\r\n}\r\n \r\nfunction view2New(){\r\n //create view 2\r\n var view2 = Ti.UI.createView({\r\n backgroundColor: 'red',\r\n });\r\n \r\n //function to create labels on each of the 2 views\r\n var mainLabelsFunction2 = function mainLabels() {\r\n Ti.API.info('****** mainLabels function has started ******');\r\n var labels =[];\r\n var label = null;\r\n for (var i=0; i < 2000; i++) {\r\n label = Ti.UI.createLabel();\r\n labels.push(labels);\r\n }\r\n Ti.API.info('Titanium labels created and added to array');\r\n Ti.API.info('****** mainLabels function has stopped ******');\r\n } \r\n //create Labels\r\n mainLabelsFunction2();\r\n mainLabelsFunction2 = null;\r\n \r\n \r\n var buttonView2 = Ti.UI.createButton({\r\n title: \"Go To View 1\"\r\n });\r\n buttonView2.addEventListener(\"click\", function(e) { \r\n view1New();\r\n Ti.API.info('****** Clean Up of View 2 ******'); \r\n\r\n //clean up View 1 \r\n view2.remove(buttonView2);\r\n buttonView2 = null;\r\n win.remove(view2);\r\n view2 = null; \r\n }); \r\n \r\n view2.add(buttonView2);\r\n //add view to main win\r\n win.add(view2); \r\n}\r\n\r\n{code}\r\n\r\nI have tested the code with the March 8th build and the March 2nd build and crashes on both builds.\r\n\r\nThank You\r\n\r\n\r\n", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T11:52:00.000+0000", "updated": "2012-03-08T11:52:00.000+0000" }, { "id": "185561", "author": { "name": "jhaynie", "key": "jhaynie", "displayName": "Jeff Haynie", "active": false, "timeZone": "America/Los_Angeles" }, "body": "This code has a bug\r\n\r\nYou are adding an array to an array (labels).\r\n\r\nI think you meant label for the var name in the loop\r\n\r\niOS will let you consume 100% of phones memory but android won't. iOS would eventually crash too", "updateAuthor": { "name": "jhaynie", "key": "jhaynie", "displayName": "Jeff Haynie", "active": false, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T12:10:32.000+0000", "updated": "2012-03-08T12:10:32.000+0000" }, { "id": "185577", "author": { "name": "mculpepper", "key": "mculpepper", "displayName": "Marshall Culpepper", "active": true, "timeZone": "America/Los_Angeles" }, "body": "@Sean\r\n\r\nCreating 2000 labels in a tight loop like that will probably never give the GC a chance to kick in. As Jeff mentioned -- one fundamental difference between Android and iOS is the amount of heap space available to apps. While all these views are created, you are also blocking the JS thread. In this case, you can run into the app-specific heap limit before the GC has a chance to even run. If you try decreasing to say, 500 labels that should give the thread a chance to properly receive a GC sweep\r\n\r\nIn Android, the total heap space per app depends on the hardware and OS version. Generally 16MB is the ultra-low end for older 1.x devices, 24MB and 32MB are the norm for 2.2 and 2.3 devices, and 48MB is used for Honeycomb and ICS devices (which also provide an optional AndroidManifest flag to enable up to 128MB of heap)\r\n\r\nIn iOS, you are basically given free range of the total heap space available to the device. In this test case, iOS may be allowing you to allocate much more memory in the loop of 2000 labels, and once it's completed, allow a GC to properly cleanup.\r\n\r\n", "updateAuthor": { "name": "mculpepper", "key": "mculpepper", "displayName": "Marshall Culpepper", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T13:30:15.000+0000", "updated": "2012-03-08T13:30:15.000+0000" }, { "id": "185578", "author": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Jeff and Sean,\r\n\r\nI also noticed your typo with Labels and label. I corrected it and tested it on my Android device and it crashes after about 10 - 15 clicks 5 min of clicking. I can upload the trace file if necessary to help debug the issue.\r\n\r\nJeff,\r\n\r\nI have ran Seans test case for about an half hour using Instruments and it never crashes and the transitory and live objects always grows and shrinks perfectly. Here are my results of running the app in Instruments. (I can click the buttons as fast as possible and the app never slows down)\r\n\r\nTiUILabelProxy: (Living/Transitory)\r\nClick 1 = 2000/0\r\nView 1 displayed = 2/0\r\nLabel Overall Bytes: 3KB\r\n\r\nClick 2 = 2000/2000\r\nView 2 displayed = 2/1\r\nLabel Overall Bytes: 3KB\r\n\r\nAfter 3 clicks Overall Bytes are 3.56 MB\r\n....\r\n....\r\n....\r\nAfter 100+ clicks overall Bytes for TiUILabelProxy is 214.84 MB\r\nTiUILabelProxy Transitory object: 220,000\r\nTiUILabelProxy Living Objects 2000 then drops to zero after 10-20 seconds of waiting. \r\n\r\nI have Seans sample app still running for over half-hour with continuous clicking trying to make it run out of memory as you suggested in iOS and can not make it crash.\r\n\r\nThank you\r\n\r\n\r\n", "updateAuthor": { "name": "mathewrain", "key": "mathewrain", "displayName": "Mathew Rain", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T13:30:25.000+0000", "updated": "2012-03-08T13:30:25.000+0000" }, { "id": "185626", "author": { "name": "mculpepper", "key": "mculpepper", "displayName": "Marshall Culpepper", "active": true, "timeZone": "America/Los_Angeles" }, "body": "@Mathew\r\n\r\nPlease see my comments above about heap size limits in Android. You won't ever make it to anything like 214MB on Android because the heap limit is much lower. On most devices you will see on the order of 24, 32, or maybe 48MB total heap if you are lucky. Eventually (if you keep clicking past 100+), iOS will also run out of system heap, but it will take longer because the app's heap is shared with the rest of the system.", "updateAuthor": { "name": "mculpepper", "key": "mculpepper", "displayName": "Marshall Culpepper", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-08T15:04:41.000+0000", "updated": "2012-03-08T15:04:41.000+0000" }, { "id": "185958", "author": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Hi Guys,\r\n\r\nI have been doing some testing and will post my results later today.\r\n\r\nThank You", "updateAuthor": { "name": "sean sean", "key": "sean sean", "displayName": "Sean Sean", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-12T08:38:32.000+0000", "updated": "2012-03-12T08:38:32.000+0000" }, { "id": "187258", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Tested with:\r\n* Android 2.2 APIs\r\n* v8\r\n* ubuntu 11.10\r\n\r\nAlthough Josh's fixed SDK (2.0.0 2012/03/07 13:43 1eb23a1) resolves this problem, the current master (03/19/12 16:32 6237693) does not.\r\n", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-19T16:21:41.000+0000", "updated": "2012-03-19T16:22:19.000+0000" }, { "id": "187280", "author": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Bug magnitude is higher in master.\r\n\r\nSDK: 2.0.0.v20120319003254\r\nAndroid: V8\r\nStudio: 2.0.0.201203182248\r\nOS: Snow Leopard\r\nDevices Tested: Android Emulator 2.2, Android Emulator 2.3.3\r\n\r\nRunning code below in emulator causes crash within ten seconds. In 1.8.2, it would take a few minutes.\r\n2.2 and 2.3.3 behavior identical. Logs attached. Not found in Android 2.2.2 Nexus One Device (tested a few minutes).\r\n\r\nSteps to Reproduce:\r\n\r\n1. Run code.\r\n\r\n{code:title=app.js}\r\nvar noOfViews = 500;\r\nvar mainViewsIterations = 0;\r\nvar interval = 3000;\r\n\r\nfunction mainViews(noOfViews) {\r\n\tTi.API.info('****** mainViews function has started ******');\r\n\tvar views =[];\r\n\tvar view = null;\r\n\tfor (var i=0; i < noOfViews; i++) {\r\n\t\tview = Ti.UI.createView();\r\n\t\tviews.push(view);\r\n\t}\r\n\tTi.API.info('Titanium views created and added to array');\r\n\tTi.API.info('****** mainViews function has stopped ******');\r\n\tmainViewsIterations++;\r\n\treturn mainViewsIterations;\r\n}\r\n\r\nvar win = Ti.UI.createWindow({\r\n\tbackgroundColor: \"white\"\r\n});\r\n\r\nvar button = Ti.UI.createButton({\r\n\ttitle: 'Interval: ' + interval + ', Views: ' + noOfViews\r\n});\r\n\r\nbutton.addEventListener(\"click\", function(e) {\r\n\tvar total = mainViews(noOfViews) * noOfViews;\r\n\tTi.API.info('Total views created: ' + total);\r\n\tbutton.title = 'Total Views Created: ' + total;\r\n});\r\n\r\nsetInterval(function(){\r\n\tbutton.fireEvent('click');\r\n}, interval);\r\n\r\nwin.add(button);\r\nwin.open();\r\n{code}\r\n\r\n2. Wait.\r\n\r\nExpected Result:\r\n\r\nApp should not crash.\r\n\r\nActual Result:\r\n\r\nCrash within 10 or so seconds.", "updateAuthor": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-19T17:05:49.000+0000", "updated": "2012-03-19T17:05:49.000+0000" }, { "id": "187597", "author": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "body": "[Pull Request #1774|https://github.com/appcelerator/titanium_mobile/pull/1774] sent to resolve JNI reference limit issue.\r\n\r\nNote about the test case in Dustin's comment. While this won't hit the JNI reference limit, it does use\r\nup a lot of heap. This is mainly due to the small internal between view creation loops. The previous loop\r\nmay not be done before the next interval fires. This gives very little time for full GC passes. I suggest\r\ninstead using a setTimeout in mainViews to schedule the next run after the loop has finished.", "updateAuthor": { "name": "joshroesslein", "key": "joshroesslein", "displayName": "Josh Roesslein", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-20T21:37:39.000+0000", "updated": "2012-03-20T21:37:39.000+0000" }, { "id": "187928", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Josh, yeah, it probably would have been better with setTimeout, but I wanted more control over it. I always make sure view creation has completing before clicking the button again.\r\n\r\nI've tested this again, and the problem seems to be resolved in:\r\n\r\n* latest Android Tools (rev17)\r\n* Android APIs 2.2 and 2.3.3\r\n* Titanium 2.0.0 (2012/03/19 16:33 6237693) (same as one I tested above)\r\n* v8\r\n* ubuntu 11.10\r\n", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-22T07:01:58.000+0000", "updated": "2012-03-22T07:01:58.000+0000" }, { "id": "187967", "author": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "body": "Hi Josh - sorry about that - I didn't realise that commenting on a resolved ticket reopens it. Marking resolved again now.", "updateAuthor": { "name": "pdowsett", "key": "pdowsett", "displayName": "Paul Dowsett", "active": true, "timeZone": "Europe/London" }, "created": "2012-03-22T09:01:00.000+0000", "updated": "2012-03-22T09:01:00.000+0000" }, { "id": "187996", "author": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Closing as Fixed.\r\n\r\nSDK: 2.0.0.v20120322091832\r\nAndroid: V8\r\nStudio: 2.0.0.201203211914\r\nOS: Snow Leopard\r\nDevices Tested: Emulator 2.2, Emulator 2.3\r\n\r\nNote: The app lasted for as long as it was tested (one minute).", "updateAuthor": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-22T10:02:24.000+0000", "updated": "2012-03-22T10:02:24.000+0000" }, { "id": "189357", "author": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Opening to edit label.", "updateAuthor": { "name": "dhyde", "key": "dhyde", "displayName": "Dustin Hyde", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-03-30T15:29:42.000+0000", "updated": "2012-03-30T15:29:42.000+0000" }, { "id": "201483", "author": { "name": "sbhadauria", "key": "sbhadauria", "displayName": "Shyam Bhadauria", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Re-opening to edit the label.", "updateAuthor": { "name": "sbhadauria", "key": "sbhadauria", "displayName": "Shyam Bhadauria", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-07-04T03:37:00.000+0000", "updated": "2012-07-04T03:37:00.000+0000" }, { "id": "201484", "author": { "name": "sbhadauria", "key": "sbhadauria", "displayName": "Shyam Bhadauria", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Labels edited", "updateAuthor": { "name": "sbhadauria", "key": "sbhadauria", "displayName": "Shyam Bhadauria", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2012-07-04T03:38:49.000+0000", "updated": "2012-07-04T03:38:49.000+0000" } ], "maxResults": 54, "total": 54, "startAt": 0 } } }