[TIMOB-5115] Memory leak on iPad app
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | High |
|---|
| Status | Closed |
|---|
| Resolution | Needs more info |
|---|
| Resolution Date | 2011-12-01T16:00:32.000+0000 |
|---|
| Affected Version/s | Release 1.7.2 |
|---|
| Fix Version/s | Sprint 2011-48 |
|---|
| Components | iOS |
|---|
| Labels | 1.7.2, look1, memory |
|---|
| Reporter | Eduardo Gomez |
|---|
| Assignee | Eduardo Gomez |
|---|
| Created | 2011-08-26T09:55:41.000+0000 |
|---|
| Updated | 2017-03-23T21:44:11.000+0000 |
|---|
Description
Problem
Labels are being stack up and never going away memory. As the attached screenshot shows up (#LIVING column has over 6300 objects).
Steps to reproduce
The steps are as follows:
{noformat}
1.) Go to the events tab
2.) Open a event and then close it
3.) Repeat opening and closing event 30-50 times
4.) The application will slow to a crawl
{noformat}
Repro sequence
The app resources are attached to ticket.
Associated HD ticket
APP-885985
Further info
The function to debug is createEventsDetailWindow. It is also maybe more like 30 times or so and it starts to really slow down. You can tell that the window starts populating slower and slower as you open and close more events.
Attachments
There's no sample code, and the helpdesk ticket is closed to me (IE, "The ticket you are trying to open is private, doesn't exist or it is not valid"). Given how often this has happened, or worse, the ticket completely lost when helpdesk platforms change, we really should insist on all information, including source, is required in the Jira ticket, and that linking to any external sources, including helpdesk, is insufficient.
Code is now there
Can I ask the status on this?
Took instruments to this again, and did some deep introspection into the Titanium engine on this one. 1) The latter windows are sticking around with a retain count of 2 2) The two unmatched retains are missing [KrollObject release] and [KrollBridge unregister]. This means it is being held due to javascript. 3) In the action of being closed, [self forgetSelf] IS being called, so the JS retention is not due to rememberself. 4) In the lifetime of the window, it is not assigned as a property to any other proxy, so the JS retention is not due to rememberProxy Therefore, the memory leak is due to JS retention, and the retention is coming from the javascript itself. I'll be talking with Eduardo on this, as 30 to 40+KB of javascript is too large for a minimum fail case.
Talked with Shaq and Eduardo. Tentatively marking this as needs more info for now, until we get a minimum fail case.
Closing ticket because the information that was requested was never provided.