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.
