4

Let me start by clarifying what this question is NOT. It's not a request for an simple explanation of how Flash memory management or garbage collection works (reference counting, mark and sweep, etc.). Nor is it a request for tips for avoiding memory leaks (like recycling renders, weak references, removing event listener, IDispose pattern, stopping timers, avoiding static pointers and pointers from global object like stage, etc.)

Assume you have a reasonably large Flex program coded in MXML and Actionscript, and assume that it is coded by persons who are reasonably conversant in all of the above, and assume it STILL has a memory leak. At this point it is necessary to debug the problem, and the question is how to do it.

The Flash Builder Premium IDE can take a memory snapshot at time A and time B, and then compare the two snapshots, and then report on "loitering" objects. To use this, a program is run to a steady state (time A), then it is run some more (time B), and the implicit assumption is that the system should contain approximately the same objects - if it doesn't then the new ones are "loitering" (the memory leak). Conveniently, the IDE will provide a list of pointers leading to each loitering object.

But the IDE doesn't appear to provide the critically important information: which of those pointers are "locking" an object in memory and preventing garbage collection, vs. which are merely pointers from child objects (cycles) that should go away naturally if the object is collected. While the IDE does flag some pointers as "gcroot", anecdotally pointers from child objects are often (usually!) flagged as gcroot so this flag doesn't provide the necessary information. Since a reasonably sized program can have a LOT of objects, and since they can be connected in a complex graph via pointers, it is difficult to use the IDE to find which pointers are causing memory leaks.

Thus, my question is, does anyone have any tips (beyond what is already mentioned above) on how to find the cause of memory leaks in a Flex program implemented in Actionscript and MXML?

CQ Bear
  • 396
  • 2
  • 4
  • 4
    [Adobe Scout](http://gaming.adobe.com/technologies/scout/) with `advanced-telemetry=true` should be able to help you, I think. Just make sure you do not do a production build with that set to true; it **will** slow down the app. – Josh Nov 14 '13 at 18:31
  • I know I have used SWF profile a couple of times (FlashDevelop) to find out what is active in code given a specific time. And when all else fails, I usually resort to killing 50% of code and see if it still happens and then just keep killing another 50% until I find the issue :( From my experience it is usually really hard to find the culprit by looking at data/output/debug so hence why I usually end up having to go the pragmatic way – Daniel MesSer Nov 14 '13 at 23:23
  • I debug my memory leaks by first watching the count of class instances via FlashDevelop's profiler, and if I see a count that grows beyond reasonable threshold, I go down to creation/release of this particular class and review it by hand. You can automate a part of this by using a static Vector of the affected class, stuff all the created instances in it (manually) and as soon as you are about to dereference an instance, splice it out of that vector, and watch it grow or not. If it doesn't grow, check if some of those objects you dereference still have event listeners attached. – Vesper Nov 15 '13 at 05:34
  • Also look at this question: http://stackoverflow.com/questions/665094/debugging-flex-as3-memory-leaks?rq=1 – Vesper Nov 15 '13 at 05:35

2 Answers2

0

Take a look at The Miner

It has a very comprehensive toolset that can profile and debug from inside the flash player.

I have used it before to identify where memory leaks where coming from, and to clean up things that could cause memory leaks later on.

AttackingHobo
  • 259
  • 3
  • 12
0

Try Monster Debugger: http://www.monsterdebugger.com/ or as someone already mentioned Adobe Scout: https://www.adobe.com/products/scout.html

Alternatively you could create your own basic profiler: http://www.flashandmath.com/howtos/memory/

Bynho
  • 572
  • 6
  • 16