[TIMOB-2299] Some ASI objects leaked

GitHub Issue	n/a
Type	Bug
Priority	Medium
Status	Closed
Resolution	Fixed
Resolution Date	2011-04-17T01:58:41.000+0000
Affected Version/s	n/a
Fix Version/s	Release 1.6.0
Components	iOS
Labels	asihttp, critical, defect, ios, leak, memory, proxy, release-1.6.0
Reporter	Stephen Tramer
Assignee	Stephen Tramer
Created	2011-04-15T03:16:02.000+0000
Updated	2011-04-17T01:58:41.000+0000

Description

Looks like some ASI objects are not released. Running the following test in instruments revealed that no ASIFormDataRequest objects are ever deallocated:

var count = 0;
function runXHR(){
    var xhr = Titanium.Network.createHTTPClient();

    xhr.onload = function()
    {
        count++;
        Ti.API.log('available memory:' + Titanium.Platform.availableMemory + ' cnt: ' + count);
    };
    // open the client
    xhr.open('GET','http://www.developedit.com/test.json');

    // send the data
    xhr.send();
}

runXHR();

setInterval(function()
{
    runXHR();
},1000);

Comments

Jeff Haynie 2011-04-15

(from [6e72cfc6d42fc819ccb2632b7ea90f777c3c6307]) [#2299 state:open] Fixes to set appropriate values. Resetting bug to open because this actually has to do with indefinite proxy retention; see bug for details. https://github.com/appcelerator/titanium_mobile/commit/6e72cfc6d42fc819ccb2632b7ea90f777c3c6307"> https://github.com/appcelerator/titanium_mobile/commit/6e72cfc6d42f...
Stephen Tramer 2011-04-15

Very bad news; this is an endemic problem throughout Titanium, the dreaded "proxy retention issue." This is because we retain proxies as part of contexts, and then NEVER release them until the context is closed. This is especially bad for HTTP requests, as we return response information in the proxy - that means that over time huge amounts of cruft may accumulate, even with just a few (expensive) HTTP requests.

Marking this bug CRITICAL even though it may not be completed before 1.5.0.
Jeff Haynie 2011-04-15

(from [93f5ab4b4fb667df89641cf97b7495321ee5b02b]) [#2299] Minor fix to handle some crashers. https://github.com/appcelerator/titanium_mobile/commit/93f5ab4b4fb667df89641cf97b7495321ee5b02b"> https://github.com/appcelerator/titanium_mobile/commit/93f5ab4b4fb6...
Jeff Haynie 2011-04-15

(from [c499a6e69be9895cce1cf02741b90f679ea34c87]) [#2299 state:fixed-in-qa] Closer conformance to XHR and plugging of memory leak. https://github.com/appcelerator/titanium_mobile/commit/c499a6e69be9895cce1cf02741b90f679ea34c87"> https://github.com/appcelerator/titanium_mobile/commit/c499a6e69be9...
Stephen Tramer 2011-04-15

How did that last commit just get discovered? It was made before the first one, and... well, who cares. Reopening the bug.
Stephen Tramer 2011-04-15

Bumping this down the road, with a note. It's two-pronged: Proxy retention issues (how we handle memory warnings is not smart right now, because it LEADS to memory warnings) and problems in Kroll involving certain objects which should be autoreleased (but never are, because they're retained at very bad points in their lifecycle).

Unfortunately at this time there's no good way to handle clearing out stale client responses, simply because there's no good way to tell when they're "stale."

This bug should be a high priority target for a 1.5.1 release due to its critical nature.
Damien Elmes 2011-04-15

Sound objects don't get released until they're explicitly .release()d - could a similar approach be taken with ASI, at least as a stop gap?
Stephen Tramer 2011-04-15

Possibly. Let me know if doing "this.release()" inside of your onload callbacks helps alleviate memory problems. This will not release the ASI request, but rather the ASI response (you will have to release your XHR objects separately).

There may be a stopgap measure put in place to handle ASI response memory management, but it will not take care of ASI request retention.
Jeff Haynie 2011-04-15

(from [eb3656b0297a2a28a4b394cd505311415bac7d14]) [#2299 state:fixed-in-qa] - Don't retain HTTP responses as if they're normal proxies - Cleanup to not use 'connected' to detect an error vs. success when sending responses; was leading to a race condition that would cause reused HTTP clients to stall - Fix for bad juju of separate alloc and init calls in TiModule https://github.com/appcelerator/titanium_mobile/commit/eb3656b0297a2a28a4b394cd505311415bac7d14"> https://github.com/appcelerator/titanium_mobile/commit/eb3656b0297a...
Stephen Tramer 2011-04-15

Bug #2616 deals with the memory management issues described earlier in this bug ticket.

Bug #2617 deals with XHR compliance in general.
Thomas Huelbert 2011-04-15

closing this record while noting the 2 open issues Stephen lists.
Thomas Huelbert 2011-04-15

should actually close it maybe

JSON Source