Skip navigation
Currently Being Moderated

Looking for memory leaks

Feb 19, 2013 12:36 PM

If I want to profile an app for memory leaks what is the best approach?

 

Thanks

 
Replies
  • Currently Being Moderated
    Feb 20, 2013 12:05 AM   in reply to Zolotoj

    See my blog post.  The UI is a bit different in FB 4, but the principles still apply.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 10:56 AM   in reply to Zolotoj

    Looks like event listeners are attached to that object.  Clicking on each function should show the call stack at the time of allocation which should help you find who is attaching listeners.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 11:43 AM   in reply to Zolotoj

    The first and very important point is to understand if your scenario allows the use of Loitering Objects view.  The profiler was designed for “create-and-destroy” scenarios, but some scenarios are cyclical and Loitering Objects will return false positives.

     

    The “art” of memory leak analysis is in the determining of which objects to worry about.  It might be ok for ReviewMessages to have 8 listeners if all of the objects involved are going to get tossed along with ReviewMessage together later.

     

    But if you are sure that ReviewMessages is not supposed to be around any more but the other objects should, the allocation trace in this case should show you what code attached the listener, and then you have to decide if there is some other API call you were supposed to make to get that code to remove the listener,  or maybe that code needs to use a weak reference listener, or maybe some API for something further down in the allocation trace is what you need to call to get that listener removed.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 12:29 PM   in reply to Zolotoj

    LoiteringObjects does not work for scenarios like this:

     

    You have one instance of a screen but every time you switch to it, you replace old instances of child objects with new objects.  LoiteringObjects only shows you what instances are in the second snapshot that weren’t in the first.  Because you created replacement objects, it will show that those are leaking but they aren’t since every time you switch you replace the old with the new.  In such a scenario, I do not use LoiteringObjects and just compare the instance counts between the two snapshots manually.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 1:42 PM   in reply to Zolotoj

    Yes, unless your app is collecting records of things on purpose.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 5:07 PM   in reply to Zolotoj

    The functions are holding the class in memory.  The allocations should give you a clue.  Feel free to post images of the allocation trace if it is in SDK code.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 22, 2013 10:10 PM   in reply to Zolotoj

    Is there an addEventListener call in StatusCountRenderer on line 10?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 23, 2013 11:23 PM   in reply to Zolotoj

    Hmm, didn’t see a match.  Try using –keep-generated-actionscript and see what it thinks is on line 10.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 24, 2013 9:10 PM   in reply to Zolotoj

    It is a compiler option.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 25, 2013 4:24 PM   in reply to Zolotoj

    What version of the Flex SDK are you using and what version of FB and FlashPlayer?  You might be missing information if the SDK and FB and FP don’t match up.

     

    Line numbers don’t match up exactly for me, so I’m assuming the UIComponent lines are the self-referencing event listeners in the constructor.

    The last function (Capture12: GroupBase: set layout) causes the layout to have a reference to the skin.  So next you need to see if anything is hanging onto the layout.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 25, 2013 9:01 PM   in reply to Zolotoj

    Go to flashplayerversion.com and see what it says about your player version.

     

    FB4.7’s profiler was probably tested with FP11.2 or FP11.3.  There is a chance that FP11.5 doesn’t report samples in a way that FB can handle.

     

    UIComponent’s constructor calls addEventListener on itself.  That can’t cause a leak.

     

    There is some layout instance assigned to those renderer instances.  They should also be in the profiler’s snapshot and you should check to see if they are getting stuck in memory somehow.  Use the debugger to see what the layout class is if you’re not sure.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2013 9:17 AM   in reply to Zolotoj

    Finding memory leaks can be very hard.  Back in the day, I’d say I got interrupted every 3 months or so by a major Adobe customer who escalated an issue through their support contract that required my assistance working with their code and the profiler.  Unfortunately, I’ve never been able to capture my methodology other than what I’ve told you so far.  A lot of it becomes “feel” where by looking at the source code and the profiler output I start to eliminate possibilities until I find out what is going on.

     

    This most recent scenario about the renderer’s skin and its layout is making me wonder if you really have a leak here.  It would probably require a custom layout that is misbehaving.  There could be other reasons why instance counts are going up.  If you resize a list or scroll it, it might create more cached instances (although then the instances should show that the cache is pointing to it).

     

    Basically you have to understand how your code works and try to get the Profiler to help you analyze it.  Sometimes there are very good reasons for instance counts to go up.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points