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" <[email protected]> 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.
