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.
