Memory leak in timer.performWithDelay

Solar2D Lua Language
#1

I noticed something strange with timer.performWithDelay and the app’s memory usage. 

I monitored the memory usage with the following code:

local function checkMemory()     collectgarbage("collect")     local memUsageStr = string.format("MEMORY = %.3f KB", collectgarbage("count"))     local textureStr = "TEXTURE = " .. (system.getInfo("textureMemoryUsed") / (1024 \* 1024))     print(memUsageStr, textureStr) end timer.performWithDelay(1000, checkMemory, 0)

And when running the following code:

local bounceUp local rect = display.newRect(0, 0, 20, 20) local transitionTimer = timer.performWithDelay(100, \_bounceUp) local function bounceOnComplete()     transitionTimer = timer.performWithDelay(3000, bounceUp) end local function bounceDown()     transition.to(rect, { time=300, y=0, transition=easing.inCirc, onComplete=bounceOnComplete }) end bounceUp = function() --timer.cancel(transitionTimer) -- I tried to add this line, but it did not help transitionTimer = nil collectgarbage()     transition.to(rect, { time=300, y=-50, transition=easing.outCirc, onComplete=bounceDown }) end

I see the memory count keeps rising up.

It increments significantly, then decrements a little bit, over and over, so overall the usage is growing continuously. 

It makes sense for the memory to rise, since I keep creating new timers, but it should also free the same amount when these timers end.  

Also, I tried the following approach to see if it helps:

local bounceUp local rect = display.newRect(0, 0, 20, 20) local transitionTimer = timer.performWithDelay(3000, \_bounceUp, 0) local function bounceDown()     transition.to(rect, { time=300, y=0, transition=easing.inCirc }) end bounceUp = function()     transition.to(rect, { time=300, y=-50, transition=easing.outCirc, onComplete=bounceDown }) end

But to my surprise, the memory usage stayed the same. 

It keeps creeping up, no matter what. 

What is going on?

Why isn’t the memory released after the timer ends?

#2

set  transitionTimer = nil and call collectgarbage() at the end of your timer to deallocate memory.

#3

I tried it, but there were no changes to the result - every time a new timer was set, the memory consumption jumped, decreased a bit after, but over all the memory consumption keeps growing and growing. 

(I edited the code to reflect the change)

#4

Any update on this?

We use timers a lot, and that means we loose  lot of memory for no reason…

Can you please investigate?

#5

Can you put together a demo project that shows the issue? It must be a complete project: main.lua, config.lua, build.settings and any other assets/files needed so we can just load it and run it and see the problem. Put that in a .zip file (no other format please) and attach it to an email sent to support AT coronalabs.com along with a good description of the problem and the steps needed to reproduce it.

Thanks

Rob

#6

I found the memory leak, it was in an internal function that wraps all “transitions.to” calls. 

So the timer was wrongfully accused :slight_smile:

Thanks for the help!

#7

set  transitionTimer = nil and call collectgarbage() at the end of your timer to deallocate memory.

#8

I tried it, but there were no changes to the result - every time a new timer was set, the memory consumption jumped, decreased a bit after, but over all the memory consumption keeps growing and growing. 

(I edited the code to reflect the change)

#9

Any update on this?

We use timers a lot, and that means we loose  lot of memory for no reason…

Can you please investigate?

#10

Can you put together a demo project that shows the issue? It must be a complete project: main.lua, config.lua, build.settings and any other assets/files needed so we can just load it and run it and see the problem. Put that in a .zip file (no other format please) and attach it to an email sent to support AT coronalabs.com along with a good description of the problem and the steps needed to reproduce it.

Thanks

Rob

#11

I found the memory leak, it was in an internal function that wraps all “transitions.to” calls. 

So the timer was wrongfully accused :slight_smile:

Thanks for the help!