Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: High High
    • Resolution: Needs more info
    • Affects Version/s: Release 1.7.2
    • Fix Version/s: Sprint 2011-48
    • Component/s: iOS
    • Labels:
    • Environment:

      Product: Mobile
      Titanium SDK: Mobile 1.7.2
      Platform OS: iOS
      Platform OS Version: 4.3

      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:

      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
      
      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.

        Activity

        Hide
        Blain Hamon (Inactive) added a comment -

        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.

        Show
        Blain Hamon (Inactive) added a comment - 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.
        Hide
        Blain Hamon (Inactive) added a comment -

        Code is now there

        Show
        Blain Hamon (Inactive) added a comment - Code is now there
        Hide
        Ryan DuVal added a comment -

        Can I ask the status on this?

        Show
        Ryan DuVal added a comment - Can I ask the status on this?
        Hide
        Blain Hamon (Inactive) added a comment -

        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.

        Show
        Blain Hamon (Inactive) added a comment - 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.
        Hide
        Blain Hamon (Inactive) added a comment -

        Talked with Shaq and Eduardo. Tentatively marking this as needs more info for now, until we get a minimum fail case.

        Show
        Blain Hamon (Inactive) added a comment - Talked with Shaq and Eduardo. Tentatively marking this as needs more info for now, until we get a minimum fail case.

          People

          • Assignee:
            Eduardo Gomez
            Reporter:
            Eduardo Gomez
          • Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development