One test would be to make a simple app with just the DateField in it and see if it goes away. That should be small enough to be able to use Flash Builder to track down any leaks.
PopUps can easily cause memory leaks. They often set up global/systemManager event listeners. PopUps are not parented by the top-level so removing the top-level doesn't cause the popUp to get removed from the display list and usually it has a reference to a shared DataProvider or the part of the control that is parented by the top-level. On the other hand, we try to write our controls like DateField to not create and parent the popup until the user actually requests it, so there are often tests where you don't open the DateField and the top-level does go away, then you open the DateField and the top-level doesn't go away. -Alex On 9/10/14 11:25 AM, "DarrenEvans" <darren.ev...@allocatesoftware.com> wrote: >Played around, commenting out stuff and think I've found what's pinning >it. > >The Explorer has an ExplorerBar, which contains a bunch of navigation >buttons and a view date component. That date component is one of ours and >is >a subclass of mx:DateField (actually a subclass of >com.jabbypanda.controls.DateField4). > >If I comment out all references to that (effectively remove it from >existence) the Explorer and ExplorerBar get cleared down. Now I obviously >need to put this component back in and cannot easily see why it is not >clearing down. I was thinking maybe the dropdown chooser (as that actually >get created when the DateField is created and we have a customisation of >that too) and I have seen mentions of leaks around that area >(https://issues.apache.org/jira/browse/FLEX-9617)... > > >Alex Harui wrote >> Well, it may not be about "clearing". But if removeAllChildren() made a >> difference, that means that the children are pinning the explorer in >> memory, and you could just start removing individual children to see >>which >> one makes a difference. >> >> I've seen a component having focus pin the component. One test is to >>add >> code to get the Explorer to go away without touching any children in the >> Explorer. Like add a Button outside the Explorer. >> >> Another time, a component hooked up a timer. The timer is then >> referencing the component and the component references the parent chain >> back to the top-level object. Use of SetInterval and SetTimeout also >> create timers under the hood. >> >> Yet another time, someone embedded an icon for a button that wasn't a >>PNG >> or JPG, it was a SWF that had a timeline animation. The player >>references >> the SWF in order to play the animation, the SWF references the button, >>the >> button references a parent chain back to the top-level object. >> >> And there are countless other scenarios where Singletons get registered >> and reference a child. >> >> -Alex > > > > > >-- >View this message in context: >http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate >-memory-leak-tp7770p7969.html >Sent from the Apache Flex Users mailing list archive at Nabble.com.
