[TIMOB-2616] KrollObject create problems
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2011-05-16T11:05:39.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 1.7.0, Sprint 2011-16 |
Components | iOS |
Labels | critical, defect, enterprise, ios, klist, kroll, leak, memory, release-1.7.0, reported-1.5.1 |
Reporter | Stephen Tramer |
Assignee | Blain Hamon |
Created | 2011-04-15T03:24:51.000+0000 |
Updated | 2011-05-16T11:05:39.000+0000 |
Description
KrollObject appears to retain itself twice within its own constructor. This is an issue because quite often these objects are meant to be autoreleased - they never will be, unless this is resolved.
From #2299:
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.
Pushing to 1.7 Kroll work. No milestone yet so tagging.
removing release- tag as it's for committed code. Using tbs-1.7.0 to find items we know need to go in the next release.
A bunch of issues fixed along these lines.
There will be further changes to eliminate other memory leaks and we must insure that we do not regress on this issue.
This does not appear to be resolved. Though static proxies (absent of listeners) appear to be releasing, proxies that do have listeners will not.
Specific test cases can be provided once this issue is clarified.
Experiencing the same thing with a project as well. Allocations continue to build over time until the app inevitably crashes. This is even true with windows in separate javascript contexts (i.e. if you're patient enough, going back and forth in a nav group in Kitchen Sink will merit the same results). Another symptom seems to be in a large tableview. If you scroll through 300-400 rows allocations will build up, then scroll back up, they will continue to build up, scroll back down, will continue to build up but never get released.
Test for recent changes:
ATTEMPT 1: Memory is released, but event listeners do not work consistently.
ATTEMPT 2: Memory is released, but event listeners do not work consistently.
ATTEMPT 3: Event listeners work, but memory is not released.
I'm noticing the same with a customer's app. Event listeners do not work in the ios_proxy_registration branch.
This test is successful (based on attempt 2, above). Memory is being released and event listeners/handlers are working.
Hoorah! :-)
Adding event listeners using method attempt 1 remains inconsistent. Attempt 3 method retains. Awkward method, regardless.
https://github.com/appcelerator/titanium_mobile/tree/ios_proxy_registration"> https://github.com/appcelerator/titanium_mobile/tree/ios_proxy_regi...
commit: ee514a640ab1150f962f
Performing additional tests on enterprise client projects.
Blain, we have reports that this is still having problems. Please fix and regress.