I took a quick look at the test case (I haven't even tried it in the
profiler yet).
I assume the test case to run is LeakByReference.mxml. In the run()
method, it keeps storing references to the new NonLeakySubComponent on
every pass, so sure, if you don't splice out the references to the old
ones, the references array is going to cause a memory leak.
Are you saying if you are seeing a memory leak if you don't use the
references array?
-Alex
On 2/24/16, 8:27 AM, "XaviConde" <javier.co...@gruposame.com> wrote:
>Hi Clint,
>
>Flash Profiler has a functionality to force garbage collection. I press
>the
>button several times and there's no instance being freed. Besides, taking
>a
>memory snapshot also forces garbage collection.
>
>On the other hand, after several hours of Flash Profiling, I have found a
>workaround by removing the property layoutObject:
>
> private function removedFromStage(event:Event):void {
> /* For good measure, the eventListener is
> removed when no longer
>needed
>*/
>
> parentApplication.removeEventListener(MouseEvent.CLICK,
>mouseClickEvent);
>
>//Stops memory leak
> this["layoutObject"]=null;
> }
>
>By removing this property (which held a CanvasLayout object added
>dynamically) now the memory usage is stable and Profiler never reports
>more
>than 1 instance of NonLeakySubcomponent ever in memory.
>
>For what I've learned from this example, calling initialize on the child
>object being added creates several objects which reference the child
>object
>itself. But when removeChild() is called, some of these circular
>references
>still exist. By forcing the removal as I've done it seems the circular
>reference is broken.
>
>I think it should be considered a bug, since removeChild() is not undoing
>all the actions of addChild(). I'm not sure if by letting it run enough
>time
>GC would remove the leaked instances; forcing the garbage collection from
>Flash Profiler has not removed them, or the related objects. This is
>happening on the latest 4.6.15 SDK.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/Memory-leak-caused-by
>-addChild-tp51677p51715.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
