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 Fri, 05 Sep 2014 15:04:23 GMT
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" <darren.evans@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.


Mime
View raw message