flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Using Adobe Scout to locate memory leak
Date Wed, 10 Sep 2014 18:40:36 GMT
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.evans@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.


Mime
View raw message