You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by DarrenEvans <da...@allocatesoftware.com> on 2014/08/27 17:06:26 UTC
Using Adobe Scout to locate memory leak
Following on from my enabling advanced telemetry thread, I am now getting
lots of lovely information coming from Adobe Scout.
I've used this tool before quite successfully to remedy some performance
problems. However, using it to locate memory leaks is leaving me scratching
my head in confusion and frustration!
I'm looking in the "Memory Allocations" tab with "Hide Garbage Collected
Objects" turned on and there are hundreds of entries in there (I've selected
the whole frame timeline). The memory of the app just keeps on creeping up
and doesn't seem to ever come down by any significant factor (some very
small drops are seen). With the size of this app I'm just getting lost on
where to really begin.....
Are there any decent guides on how to use Adobe Scout for memory leak
detection?
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
I don't see DateField in the loitering objects, so it doesn't look like it
is leaking, per-se. I mentioned earlier that Loitering Objects has one
"flaw": it only reports objects in the second snapshot that aren't in the
first, so if you had 7 EmbeddedFont instances in the first one that were
tossed and replaced with 7 new instances, Loitering Objects shows those 7
new instances. It isn't tracking the total number of instances. So
that's what I'd do next: look at how many EmbeddedFont instances are in
snapshot 1 and compare against snapshot 2. If it is the same, it is a
false positive. If the number of instances did grow, run the scenario
again and see if it actually does keep growing. Then examine the
allocation traces to see who is allocating them. If, for example, there
is a mouse event handler that replaces an array, the number of new objects
can be affected by how many mouse move events were dispatched during the
execution of the scenario, or because you rolled over some other UI widget
accidentally during execution of the scenario.
HTH,
-Alex
On 9/16/14 1:08 AM, "DarrenEvans" <da...@allocatesoftware.com>
wrote:
>Ok, so I've modified the code to eliminate JabbyPanda's DataField4
>component
>and creat mx:DateField controls instead.
>
>Modifying the steps so that I create and remove a DateField before taking
>snapshot, then doing it again I still get the following stuff loitering:
>http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Profiler-Add-D
>ateField-Controls.png
>
>Surely the basic DateField is leaking.
>
>
>Alex Harui wrote
>> The first time you run code, it can create new Class and Function
>>objects.
>> I would probably create and remove once, then take a starting snapshot.
>> If the component is leaking, it usually will show up in subsequent
>> snapshots, unless there is some first-time initialization code.
>>
>> The class and function objects shouldn't cause leaks: they are tied to
>>the
>> SWF that brought them in. I'm a bit surprised that two managers were
>> instantiated, but I don't know the code well enough OTOH to say that it
>>is
>> a problem.
>>
>> -Alex
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p8003.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Ok, so I've modified the code to eliminate JabbyPanda's DataField4 component
and creat mx:DateField controls instead.
Modifying the steps so that I create and remove a DateField before taking
snapshot, then doing it again I still get the following stuff loitering:
http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Profiler-Add-DateField-Controls.png
Surely the basic DateField is leaking.
Alex Harui wrote
> The first time you run code, it can create new Class and Function objects.
> I would probably create and remove once, then take a starting snapshot.
> If the component is leaking, it usually will show up in subsequent
> snapshots, unless there is some first-time initialization code.
>
> The class and function objects shouldn't cause leaks: they are tied to the
> SWF that brought them in. I'm a bit surprised that two managers were
> instantiated, but I don't know the code well enough OTOH to say that it is
> a problem.
>
> -Alex
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p8003.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
The first time you run code, it can create new Class and Function objects.
I would probably create and remove once, then take a starting snapshot.
If the component is leaking, it usually will show up in subsequent
snapshots, unless there is some first-time initialization code.
The class and function objects shouldn't cause leaks: they are tied to the
SWF that brought them in. I'm a bit surprised that two managers were
instantiated, but I don't know the code well enough OTOH to say that it is
a problem.
-Alex
On 9/15/14 8:54 AM, "DarrenEvans" <da...@allocatesoftware.com>
wrote:
>Took your advice and created a test app that adds and removes DateField4
>components, directly and onto a comparative ExplorerBar component for
>experiments.
>
>Now, last time I tried to show some code on here directly all the CDATA
>stuff couldn't be seen. So I've uploaded it as a files this time (you'll
>need the jabbypanda component if you wanted to check it out completely).
>
>Main.mxml
><http://apache-flex-users.2333346.n4.nabble.com/file/n7995/Main.mxml>
>ExplorerBar.mxml
><http://apache-flex-users.2333346.n4.nabble.com/file/n7995/ExplorerBar.mxm
>l>
>
>I'm not getting the same leaks but looking at the loitering objects I'm
>getting stuff left over.
>
>So running up that application in profiler, if after it loads I do the
>following steps:
>1. Press "Run garbage collector" a few times
>2. Take a snapshot.
>3. Press "Create Date" 5 times.
>4. Press "Remove Dates"
>5. Press "Allocate some memory" (just so the gc sweep can be kicked)
>6. Press "Clear allocated memory"
>7. Press "Run garbage collector" a few times
>8. Take a snapshot
>9. Press "Find loitering objects" on the 2 snapshots.
>
>I then get the following loitering objects:
>http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Profiler-Add-D
>ateField4-Controls.png
>
>....Of which I would expect none. Is this expected behaviour? Should it be
>totally clear? Are these genuine leaks?
>
>I get a similar (if not the same set of leaks) if I swap the DateField4
>component for the basic mx:DateField component.
>
>
>Alex Harui wrote
>> That is a weird one. Nothing obvious I can see. It might be time to
>> create a simple test case.
>>
>> In could also be an interaction where the setting of the height isn't
>>the
>> problem, it is the setting of the height along with something else. To
>> test that, remove everything except the height=20 and see if it is
>>still a
>> problem.
>>
>> -Alex
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p7995.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Took your advice and created a test app that adds and removes DateField4
components, directly and onto a comparative ExplorerBar component for
experiments.
Now, last time I tried to show some code on here directly all the CDATA
stuff couldn't be seen. So I've uploaded it as a files this time (you'll
need the jabbypanda component if you wanted to check it out completely).
Main.mxml
<http://apache-flex-users.2333346.n4.nabble.com/file/n7995/Main.mxml>
ExplorerBar.mxml
<http://apache-flex-users.2333346.n4.nabble.com/file/n7995/ExplorerBar.mxml>
I'm not getting the same leaks but looking at the loitering objects I'm
getting stuff left over.
So running up that application in profiler, if after it loads I do the
following steps:
1. Press "Run garbage collector" a few times
2. Take a snapshot.
3. Press "Create Date" 5 times.
4. Press "Remove Dates"
5. Press "Allocate some memory" (just so the gc sweep can be kicked)
6. Press "Clear allocated memory"
7. Press "Run garbage collector" a few times
8. Take a snapshot
9. Press "Find loitering objects" on the 2 snapshots.
I then get the following loitering objects:
http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Profiler-Add-DateField4-Controls.png
....Of which I would expect none. Is this expected behaviour? Should it be
totally clear? Are these genuine leaks?
I get a similar (if not the same set of leaks) if I swap the DateField4
component for the basic mx:DateField component.
Alex Harui wrote
> That is a weird one. Nothing obvious I can see. It might be time to
> create a simple test case.
>
> In could also be an interaction where the setting of the height isn't the
> problem, it is the setting of the height along with something else. To
> test that, remove everything except the height=20 and see if it is still a
> problem.
>
> -Alex
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7995.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
That is a weird one. Nothing obvious I can see. It might be time to
create a simple test case.
In could also be an interaction where the setting of the height isn't the
problem, it is the setting of the height along with something else. To
test that, remove everything except the height=20 and see if it is still a
problem.
-Alex
On 9/10/14 3:00 PM, "DarrenEvans" <da...@allocatesoftware.com>
wrote:
>So further to this....I'm baffled!
>
>I've tracked down the line that is causing the leak. However, I'm at a
>loss
>as to why. In the constructor of jabbypanda's DataField4 it does the
>following (bearing mind it extends mx.controls.DateField):
>
> public function DateField4() {
> super();
>
> // Allow manual text date input.
> editable = true;
>
> height = 20;
>
> labelFunction = displayDate;
> parseFunction = DateUtil.parseStringToDate;
>
> this.addEventListener(CalendarLayoutChangeEvent.CHANGE,
>onChangeDate);
> this.addEventListener(FlexEvent.ENTER, onEnterKeyPressed);
> this.addEventListener(FocusEvent.FOCUS_IN, onFocusIn);
> }
>
>Now, if I comment out the line that sets the height = 20 the leak
>disappears. WTF?!
>
>Github link to the source code: https://github.com/JabbyPanda/DateField4
>
>
>DarrenEvans wrote
>> Great suggestion. Might do that to track down the problem as I have
>>proved
>> something else.
>>
>> After investigation we are using the 0.5.swc of
>> com.jabbypanda.controls.DateField. This has not been touched or even
>> looked at within our system for YEARS. Looking online there is a 0.51 of
>> this component and maybe even a newer Flex 4 version (I think the one I
>> can see supercedes the one we are using).
>>
>> I have now proven the leak is specifically related to the jabbypanda
>>code!
>> If I change our component to subclass directly the basic mx:DateField
>> rather than the jabbypanda one, all the memory leaks in this area
>> disappear.
>>
>> So.....think I'm getting there...
>> Alex Harui wrote
>>> 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
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p7973.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
So further to this....I'm baffled!
I've tracked down the line that is causing the leak. However, I'm at a loss
as to why. In the constructor of jabbypanda's DataField4 it does the
following (bearing mind it extends mx.controls.DateField):
public function DateField4() {
super();
// Allow manual text date input.
editable = true;
height = 20;
labelFunction = displayDate;
parseFunction = DateUtil.parseStringToDate;
this.addEventListener(CalendarLayoutChangeEvent.CHANGE,
onChangeDate);
this.addEventListener(FlexEvent.ENTER, onEnterKeyPressed);
this.addEventListener(FocusEvent.FOCUS_IN, onFocusIn);
}
Now, if I comment out the line that sets the height = 20 the leak
disappears. WTF?!
Github link to the source code: https://github.com/JabbyPanda/DateField4
DarrenEvans wrote
> Great suggestion. Might do that to track down the problem as I have proved
> something else.
>
> After investigation we are using the 0.5.swc of
> com.jabbypanda.controls.DateField. This has not been touched or even
> looked at within our system for YEARS. Looking online there is a 0.51 of
> this component and maybe even a newer Flex 4 version (I think the one I
> can see supercedes the one we are using).
>
> I have now proven the leak is specifically related to the jabbypanda code!
> If I change our component to subclass directly the basic mx:DateField
> rather than the jabbypanda one, all the memory leaks in this area
> disappear.
>
> So.....think I'm getting there...
> Alex Harui wrote
>> 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
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7973.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Great suggestion. Might do that to track down the problem as I have proved
something else.
After investigation we are using the 0.5.swc of
com.jabbypanda.controls.DateField. This has not been touched or even looked
at within our system for YEARS. Looking online there is a 0.51 of this
component and maybe even a newer Flex 4 version (I think the one I can see
supercedes the one we are using).
I have now proven the leak is specifically related to the jabbypanda code!
If I change our component to subclass directly the basic mx:DateField rather
than the jabbypanda one, all the memory leaks in this area disappear.
So.....think I'm getting there...
Alex Harui wrote
> 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
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7971.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
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" <da...@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.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
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.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
On 9/10/14 2:40 AM, "DarrenEvans" <da...@allocatesoftware.com>
wrote:
>
>I suspected something to do with last thing thing that had focus too but
>couldn't determine if that was the case. I have made a bit of progress
>this
>morning in that I can get rid of it now. In the dispose() method I was
>manually removing and disposing everything it created. As a last ditch
>attempt I shoved a removeAllChildren() at the end and that seems to have
>got
>rid of it!
>
>So from that I'm guessing something that I'm not creating is not getting
>cleared for some reason.....
>
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
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Yes, unfortunately the FlashProfiler can only take me so far before I have to
switch to Scout and as you rightly say it's not so good for locating what is
holding references.
So some background first.
Explorer is an Actionscript component extending VBox. It's added to a
SuperTabNavigator (FlexLib one) using the following code:
private function AddExplorer(loadInitialTool:Boolean=true,
initialToolEvent:ShellEvent=null):void {
var newChild:Container = CreateExplorer();
if (newChild is IExplorer) {
IExplorer(newChild).LoadInitialTool = loadInitialTool;
if (initialToolEvent) IExplorer(newChild).InitialToolEvent =
initialToolEvent;
}
tabNavigator.addChildAt(newChild, tabNavigator.numChildren);
SetMultipleTabsCloseable();
}
private function CreateExplorer():Container {
var explorer:Container = new Configuration.Factory.Explorer();
explorer.addEventListener(FlexEvent.CREATION_COMPLETE, ExplorerCreated);
return explorer;
}
Not the tidiest (mixtures of concrete and interface usage) but nothing
complicated.
I suspected something to do with last thing thing that had focus too but
couldn't determine if that was the case. I have made a bit of progress this
morning in that I can get rid of it now. In the dispose() method I was
manually removing and disposing everything it created. As a last ditch
attempt I shoved a removeAllChildren() at the end and that seems to have got
rid of it!
So from that I'm guessing something that I'm not creating is not getting
cleared for some reason.....
Alex Harui wrote
> I have not used Scout much, and never used Scout for determining _why_
> something is stuck in memory. It isn't clear to me that it is designed to
> do that. The UI and examples seem to be oriented towards showing you
> _what_ is stuck, and can show you the stack at the time of allocation, but
> doesn't appear to show you back-references like Flash Builder.
>
> Is Explorer a display object? If so, all of its children are pointing to
> it, and so are its parents. If one child is stuck in memory because it
> added an event listener to the stage or was the last widget with focus,
> Explorer will be stuck as well. Or did you remove all children?
>
> Is Explorer created from an MXML tag? If so, the containing MXML file
> likely has references to Explorer as well.
>
> Trying to comment out large sections of your app to reduce allocations so
> Flash Builder can show you back-references may still be worth considering.
>
> HTH,
> -Alex
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7962.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
I have not used Scout much, and never used Scout for determining _why_
something is stuck in memory. It isn't clear to me that it is designed to
do that. The UI and examples seem to be oriented towards showing you
_what_ is stuck, and can show you the stack at the time of allocation, but
doesn't appear to show you back-references like Flash Builder.
Is Explorer a display object? If so, all of its children are pointing to
it, and so are its parents. If one child is stuck in memory because it
added an event listener to the stage or was the last widget with focus,
Explorer will be stuck as well. Or did you remove all children?
Is Explorer created from an MXML tag? If so, the containing MXML file
likely has references to Explorer as well.
Trying to comment out large sections of your app to reduce allocations so
Flash Builder can show you back-references may still be worth considering.
HTH,
-Alex
On 9/9/14 1:37 AM, "DarrenEvans" <da...@allocatesoftware.com> wrote:
>I have got it clearing down pretty much all of the Explorer's references
>using IDisposable approach but still can't work out why it is not cleared
>itself.
>
>Here's the screenshots:
>http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Explorer-TopDo
>wn.png
>
>http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Explorer-Botto
>mUp-Objects.png
>
>
>Alex Harui wrote
>> Can you post a link to a screenshot of Scout showing the references to
>>the
>> explorer instance?
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p7947.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
I have got it clearing down pretty much all of the Explorer's references
using IDisposable approach but still can't work out why it is not cleared
itself.
Here's the screenshots:
http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Explorer-TopDown.png
http://i629.photobucket.com/albums/uu19/drevans112/Allocate/Explorer-BottomUp-Objects.png
Alex Harui wrote
> Can you post a link to a screenshot of Scout showing the references to the
> explorer instance?
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7947.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
Can you post a link to a screenshot of Scout showing the references to the
explorer instance?
On 9/5/14 1:38 AM, "DarrenEvans" <da...@allocatesoftware.com> wrote:
>Thanks Alex, useful information.
>
>The scenario we have is "perform a bunch of steps" and the memory just
>keeps
>on going up never to come back down. Do it enough and the application
>crashes, which is what the customers are reporting.
>
>Our application has a "ShellBody" and in that we have a TabNavigator. Each
>"tab" created has an "explorer" and each "explorer" has a bunch of "tools"
>in an accordian component. If we open a new tab/tabs and then close them
>down the "explorer" reference in each tab is being held and therefore all
>the memory associated with the "explorer" tree is not released.
>
>With the help of FlashBuilder we found the first held reference to
>explorer
>was an eventListener on stage pointing to a handler in the explorer.
>Introducing the IDisposable concept and manually clearing event listeners
>cleared up that problem. That was a success in our simple test app and the
>memory started dropping.
>
>However, applying those changes to our main application we are still
>seeing
>an explorer reference being held for each tab opened. According to Scout
>the
>references are event listeners setup in UIComponent (of the explorer which
>extends mx:VBox) which are "local" listeners rather than strong long lived
>objects setting up event listeners. Don't know where to look to find out
>why....
>
>Will have a look at that localConnection hack to see if that can aid us in
>finding the hanging reference.
>
>
>Alex Harui wrote
>> I don't think there is a loitering objects computation in Scout. Plus,
>> even in FlashBuilder, you can't always use Loitering Objects to solve a
>> memory leak problem. There are two kinds of memory leak scenarios
>> described on my blog [2]. Loitering objects only helps with one of them
>> and there have been many occasions when I've had the "other" scenario.
>>
>> Fundamentally, loitering objects compares two memory snapshots and
>>reports
>> which objects were in the second snapshot that weren't in the first one.
>> Loitering Objects computations are therefore useless when objects are
>> supposed to get tossed and re-instantiated. Like if you refresh data
>> every 10 seconds. If you had 8 data items, threw them out, and created
>>8
>> new ones, Loitering Objects says those 8 are loitering. Which they are,
>> but that isn't a leak.
>>
>> So first, what is your scenario? Is it one of those, "I leave the
>> application on overnight and when I come back it has crashed from being
>> out of memory"? Or "If users perform this sequence of steps often
>>enough,
>> the app crashed from being out of memory".
>>
>> Then try to look at the Scout data. You may have to write down one
>> screenful of the allocations and manually compare to what you see a few
>> minutes later, but if memory is growing, the amount of memory allocated
>>is
>> also growing and the amount of memory allocated to certain classes or
>> objects is growing and probably shouldn't and you'll have to keep
>>digging
>> until you find out what it is. When I can't use Loitering Objects in
>> Flash Builder, that's what I have to do: I manually compare two memory
>> snapshots. Painful, but works every time.
>>
>> One other thing: If your app is too big to be profiled by FlashBuilder,
>>it
>> is a hint that your app could use better modularity. Unless the sequence
>> of steps to reproduce the memory leak is extraordinarily complex, you
>> should be able to execute the few steps to get directly to the memory
>>leak
>> scenario without allocating nearly the amount of objects that you might
>> otherwise do if you are actually using the application. Think of a ship
>> with the sealable doors to stop the ship from sinking when one
>>compartment
>> springs a leak. Proper modularity should, in most cases, allow you to
>> disable parts of the app to help eliminate whole sections from being the
>> culprit of a memory leak, and thus reduce the allocation count to the
>> point where FlashBuilder can handle it. Also, there is a "flaw" in the
>> garbage collector in Flash in that the mark and sweep algorithm doesn't
>> really know what pieces of memory are memory pointers and what is data.
>> I've never seen it happen, but they tell me that the more memory you
>> allocate, the more likely you will get memory pointers that look like
>>your
>> data and that can fool the collector into not collecting objects that
>> should be free. Also, the collector is supposed to be "opportunistic"
>>in
>> that it is supposed to stop collecting if too much time has gone by in
>>the
>> frame, so in theory, it is possible to "out run" the GC by creating
>> objects faster than it can find and collect.
>>
>> BTW, the LocalConnection hack supposedly still works and supposedly
>>fully
>> cleans everything, so you might try that if you haven't. But again, it
>> can still be fooled by data looking like pointers.
>>
>> HTH,
>> -Alex
>>
>> [2]
>>
>>http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p7886.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Yup using that with mixed success.
jmclean wrote
> Have you tried clicking on the Force Garbage Collection icon (the garbage
> bin) in memory allocations tab? I find that usually narrows the issue down
> quite quickly.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7946.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Will have a look at that localConnection hack to see if that can aid us in finding the hanging reference.
Have you tried clicking on the Force Garbage Collection icon (the garbage bin) in memory allocations tab? I find that usually narrows the issue down quite quickly.
Thanks,
Justin
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Thanks Alex, useful information.
The scenario we have is "perform a bunch of steps" and the memory just keeps
on going up never to come back down. Do it enough and the application
crashes, which is what the customers are reporting.
Our application has a "ShellBody" and in that we have a TabNavigator. Each
"tab" created has an "explorer" and each "explorer" has a bunch of "tools"
in an accordian component. If we open a new tab/tabs and then close them
down the "explorer" reference in each tab is being held and therefore all
the memory associated with the "explorer" tree is not released.
With the help of FlashBuilder we found the first held reference to explorer
was an eventListener on stage pointing to a handler in the explorer.
Introducing the IDisposable concept and manually clearing event listeners
cleared up that problem. That was a success in our simple test app and the
memory started dropping.
However, applying those changes to our main application we are still seeing
an explorer reference being held for each tab opened. According to Scout the
references are event listeners setup in UIComponent (of the explorer which
extends mx:VBox) which are "local" listeners rather than strong long lived
objects setting up event listeners. Don't know where to look to find out
why....
Will have a look at that localConnection hack to see if that can aid us in
finding the hanging reference.
Alex Harui wrote
> I don't think there is a loitering objects computation in Scout. Plus,
> even in FlashBuilder, you can't always use Loitering Objects to solve a
> memory leak problem. There are two kinds of memory leak scenarios
> described on my blog [2]. Loitering objects only helps with one of them
> and there have been many occasions when I've had the "other" scenario.
>
> Fundamentally, loitering objects compares two memory snapshots and reports
> which objects were in the second snapshot that weren't in the first one.
> Loitering Objects computations are therefore useless when objects are
> supposed to get tossed and re-instantiated. Like if you refresh data
> every 10 seconds. If you had 8 data items, threw them out, and created 8
> new ones, Loitering Objects says those 8 are loitering. Which they are,
> but that isn't a leak.
>
> So first, what is your scenario? Is it one of those, "I leave the
> application on overnight and when I come back it has crashed from being
> out of memory"? Or "If users perform this sequence of steps often enough,
> the app crashed from being out of memory".
>
> Then try to look at the Scout data. You may have to write down one
> screenful of the allocations and manually compare to what you see a few
> minutes later, but if memory is growing, the amount of memory allocated is
> also growing and the amount of memory allocated to certain classes or
> objects is growing and probably shouldn't and you'll have to keep digging
> until you find out what it is. When I can't use Loitering Objects in
> Flash Builder, that's what I have to do: I manually compare two memory
> snapshots. Painful, but works every time.
>
> One other thing: If your app is too big to be profiled by FlashBuilder, it
> is a hint that your app could use better modularity. Unless the sequence
> of steps to reproduce the memory leak is extraordinarily complex, you
> should be able to execute the few steps to get directly to the memory leak
> scenario without allocating nearly the amount of objects that you might
> otherwise do if you are actually using the application. Think of a ship
> with the sealable doors to stop the ship from sinking when one compartment
> springs a leak. Proper modularity should, in most cases, allow you to
> disable parts of the app to help eliminate whole sections from being the
> culprit of a memory leak, and thus reduce the allocation count to the
> point where FlashBuilder can handle it. Also, there is a "flaw" in the
> garbage collector in Flash in that the mark and sweep algorithm doesn't
> really know what pieces of memory are memory pointers and what is data.
> I've never seen it happen, but they tell me that the more memory you
> allocate, the more likely you will get memory pointers that look like your
> data and that can fool the collector into not collecting objects that
> should be free. Also, the collector is supposed to be "opportunistic" in
> that it is supposed to stop collecting if too much time has gone by in the
> frame, so in theory, it is possible to "out run" the GC by creating
> objects faster than it can find and collect.
>
> BTW, the LocalConnection hack supposedly still works and supposedly fully
> cleans everything, so you might try that if you haven't. But again, it
> can still be fooled by data looking like pointers.
>
> HTH,
> -Alex
>
> [2]
> http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7886.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
I don't think there is a loitering objects computation in Scout. Plus,
even in FlashBuilder, you can't always use Loitering Objects to solve a
memory leak problem. There are two kinds of memory leak scenarios
described on my blog [2]. Loitering objects only helps with one of them
and there have been many occasions when I've had the "other" scenario.
Fundamentally, loitering objects compares two memory snapshots and reports
which objects were in the second snapshot that weren't in the first one.
Loitering Objects computations are therefore useless when objects are
supposed to get tossed and re-instantiated. Like if you refresh data
every 10 seconds. If you had 8 data items, threw them out, and created 8
new ones, Loitering Objects says those 8 are loitering. Which they are,
but that isn't a leak.
So first, what is your scenario? Is it one of those, "I leave the
application on overnight and when I come back it has crashed from being
out of memory"? Or "If users perform this sequence of steps often enough,
the app crashed from being out of memory".
Then try to look at the Scout data. You may have to write down one
screenful of the allocations and manually compare to what you see a few
minutes later, but if memory is growing, the amount of memory allocated is
also growing and the amount of memory allocated to certain classes or
objects is growing and probably shouldn't and you'll have to keep digging
until you find out what it is. When I can't use Loitering Objects in
Flash Builder, that's what I have to do: I manually compare two memory
snapshots. Painful, but works every time.
One other thing: If your app is too big to be profiled by FlashBuilder, it
is a hint that your app could use better modularity. Unless the sequence
of steps to reproduce the memory leak is extraordinarily complex, you
should be able to execute the few steps to get directly to the memory leak
scenario without allocating nearly the amount of objects that you might
otherwise do if you are actually using the application. Think of a ship
with the sealable doors to stop the ship from sinking when one compartment
springs a leak. Proper modularity should, in most cases, allow you to
disable parts of the app to help eliminate whole sections from being the
culprit of a memory leak, and thus reduce the allocation count to the
point where FlashBuilder can handle it. Also, there is a "flaw" in the
garbage collector in Flash in that the mark and sweep algorithm doesn't
really know what pieces of memory are memory pointers and what is data.
I've never seen it happen, but they tell me that the more memory you
allocate, the more likely you will get memory pointers that look like your
data and that can fool the collector into not collecting objects that
should be free. Also, the collector is supposed to be "opportunistic" in
that it is supposed to stop collecting if too much time has gone by in the
frame, so in theory, it is possible to "out run" the GC by creating
objects faster than it can find and collect.
BTW, the LocalConnection hack supposedly still works and supposedly fully
cleans everything, so you might try that if you haven't. But again, it
can still be fooled by data looking like pointers.
HTH,
-Alex
[2]
http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html
On 9/4/14 2:40 AM, "DarrenEvans" <da...@allocatesoftware.com> wrote:
>Yes, read that, it was one of the first ones. Gives a reasonable overview
>on
>how memory is allocated but doesn't really get down to the details of
>working with the results Scout gives to locate leaks.
>
>In our application's architecture we have a common framework and then the
>main application sits on top of this. I had more success getting a very
>basic application (sitting on the framework) compiling in FlashBuilder and
>then using the profiler in that so I could fix any framework leaks first.
>The loitering objects functionality seems a bit more useful (although not
>100% correct) and we have found the biggest part of the leak in the
>framework code using those tools.
>
>I cannot use the FlashBuilder profiler for our main Application as it's
>too
>big for it to handle. It's REALLY slow and normally crashes after a few
>minutes. So...... back to Adobe Scout to work out where the memory is
>going
>in the application. Is there anything like the loitering objects
>functionality in FlashBuilder profiler?
>
>
>Alex Harui wrote
>> Have you read this:
>> http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770p7853.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by DarrenEvans <da...@allocatesoftware.com>.
Yes, read that, it was one of the first ones. Gives a reasonable overview on
how memory is allocated but doesn't really get down to the details of
working with the results Scout gives to locate leaks.
In our application's architecture we have a common framework and then the
main application sits on top of this. I had more success getting a very
basic application (sitting on the framework) compiling in FlashBuilder and
then using the profiler in that so I could fix any framework leaks first.
The loitering objects functionality seems a bit more useful (although not
100% correct) and we have found the biggest part of the leak in the
framework code using those tools.
I cannot use the FlashBuilder profiler for our main Application as it's too
big for it to handle. It's REALLY slow and normally crashes after a few
minutes. So...... back to Adobe Scout to work out where the memory is going
in the application. Is there anything like the loitering objects
functionality in FlashBuilder profiler?
Alex Harui wrote
> Have you read this:
> http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7853.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Using Adobe Scout to locate memory leak
Posted by Alex Harui <ah...@adobe.com>.
Have you read this:
http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html
On 8/27/14 8:06 AM, "DarrenEvans" <da...@allocatesoftware.com>
wrote:
>Following on from my enabling advanced telemetry thread, I am now getting
>lots of lovely information coming from Adobe Scout.
>
>I've used this tool before quite successfully to remedy some performance
>problems. However, using it to locate memory leaks is leaving me
>scratching
>my head in confusion and frustration!
>
>I'm looking in the "Memory Allocations" tab with "Hide Garbage Collected
>Objects" turned on and there are hundreds of entries in there (I've
>selected
>the whole frame timeline). The memory of the app just keeps on creeping up
>and doesn't seem to ever come down by any significant factor (some very
>small drops are seen). With the size of this app I'm just getting lost on
>where to really begin.....
>
>Are there any decent guides on how to use Adobe Scout for memory leak
>detection?
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate
>-memory-leak-tp7770.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.