Well... it's not technically leaking... it just appears like it is because the timer is firing every 10 ms which doesn't let garbage collection run as fast as you think it should.
It will eventually run... you just have to wait a really long time. (Most likely when your physical ram is full.) In flash player garbage collection is a black box and although there are some weird hacks you can implement to force it to run it's best just to let it do it's thing. Ideally you'd just slow down this timer down to give back a few frames to let garbage collection run. Here's an article that gives you an idea of what the player is doing. http://www.craftymind.com/updated-elastic-racetrack-for-flash-9-and-avm2/ The gist is you need to yield code execution to the next frame. (i.e. wait for next Event.ENTER_FRAME). The concept is called green threading. Try playing with framerate (max 60 because of the refresh rate of your monitor) and the timer duration to see the garbage collection run more often. This is also a lesson in using the "new" keyword. If you reuse existing instances instead of making new ones, Flash Player doesn't need the extra frames to run gc. On Wed, Feb 24, 2016 at 12:20 AM, XaviConde <javier.co...@gruposame.com> wrote: > Thanks Clint, but I've commented it as well and the memory leak is still > happening. Profiler still reports memory constantly increasing. I've also > commented the other addEventListener calls just in case, and the only way > to > stop the leak is by commenting on addEventListener(). Did the Flash > Profiler > memory graph stop increasing in your test? > > Thanks in advance! > > > > > -- > View this message in context: > http://apache-flex-development.2333347.n4.nabble.com/Memory-leak-caused-by-addChild-tp51677p51700.html > Sent from the Apache Flex Development mailing list archive at Nabble.com. >
