Because this comment/code in NonLeakySubComponent.mxml is false and isn't a weak ref.
/* This is not a memory leak, because BindingUtils uses weak references */ BindingUtils.bindSetter(dataProviderChanged,this,"dataProvider"); This would work: BindingUtils.bindSetter(dataProviderChanged,this,"dataProvider", false, true); //true is useWeakReference On Tue, Feb 23, 2016 at 8:46 AM, XaviConde <javier.co...@gruposame.com> wrote: > Hi everyone, > > I'm investigating memory leaks in an application, and since the codebase is > very complex, I've downloaded a simple project from > http://dreamingwell.com/articles/archives/2008/05/understanding-m.php to > understand what causes a memory leak and what doesn't. The Flash Builder > project can be found here: > http://dreamingwell.com/examples/flex/memoryleak/MemoryLeakTest.zip. > > In short, despite I follow the instructions about how to 'fix' the sample > memory leak, the application still increases its memory usage. > > These are the steps I follow: > > 1. Donwload > http://dreamingwell.com/examples/flex/memoryleak/MemoryLeakTest.zip. > 2. Import into Flash Builder as a new project. It asks to update from Flex > Builder 3. I choose to use SDK 4.6.0. > 3. Run Flash Profiler. Live Objects view shows the counts for > NonLeakySubComponent class increasing, and memory graph increases > constantly > as well. > 4. Uncomment `references.splice( references.indexOf(lastInstance),1);' from > LeakByReference.mxml:run(). This should fix the memory leak according to > the > comments. > 5. Run Flash Profiler. Live Objects view still shows the counts for > NonLeakySubComponent class increasing, and memory graph increases > constantly > as well. > 6. Comment this.addChild(subComponent) from LeakByReference.mxml:run(). > Notice that there's a this.removeChild(subComponent) at the beginning of > the > function. > 7. Run Profiler. This time, only one instance of NonLeakySubcomponent is > displayed, and memory never increases. > > I would like to understand why this.removeChild() is not freeing the > NonLeakySubComponent object, as it should (or why addChild() is creating a > strong reference to it which causes the GC not to free it after calling > removeChild()). > > Thanks in advance. > > > > > -- > View this message in context: > http://apache-flex-development.2333347.n4.nabble.com/Memory-leak-caused-by-addChild-tp51677.html > Sent from the Apache Flex Development mailing list archive at Nabble.com. >
