The Flex 3 profiler showed circular references, although it didn't mark
them. In many cases the number of paths it could show you were
overwhelming, and by the time you dug down far enough, you were lost as to
where you were. Still, it might be worth an enhancement request.
Very large apps do seem to blow up the Profiler. Hopefully you've used best
practices and modularized the app so you can easily disable code not needed
to investigate this particular leak. That will reduce the amount of data
the Profiler has to consume and it will be more stable and fast.
By disabling code, you will hopefully be able to narrow down the candidates
to a few and inspect them more carefully.
Also, if you are using AIR, it has a bug where it does not show listeners to
some flash.desktop class instances.
Thanks for the tip on FB3. I loaded it up in FB3 and indeed it does show some recursion action going on. Everything it shows in the references to UIPage should be contained within the UIPage and therefore they should all be gc'd together. I've looked through a number of the children and related objects but see nothing outside of the UIPage (the parent wrapper) that is touching anything inside UIPage or its children. Removing/commenting out portions of UIPage to pinpoint the problem is quite difficult and frankly may not be worth our time. Pointers on where to go next would be much appreciated, but I understand there isn't much to go off of.
(BTW, is it just me or is FB3's profiler faster and more stable? No java heap errors.)
Message was edited by: Aaronius9er9er
FB3 profiler uses less heap and responds faster because it isn't trying to
find circular paths, but FB4 saves me more time because I don't have to look
at those circular paths.
The screen shot shows that there are lots of paths to investigate. One
trick you might try is calling removeAllChildren when you're done with a
UIPage and see if the UIPage then goes away. If it does, then it is one of
the children. If not, start looking at the non-children sub-objects.