General memory leak principles? (Lua)

SDK Get Help
1

I’ve bookmarked some great techniques here (thanks, Matt!) for tracking down memory leaks, but on a high level, what kinds of culprits should one look for?

For instance is .new anything without later setting it to nil or re-using it a no-no?

(I’ve tried to make every image and samplePlayer in my game be a declared variable that gets re-used in case that helps. It seemed to.)

Or are memory leaks always SDK bugs? I’ve seen some suggest that, in which case I’d stop trying to chase the issue down and focus instead on a) using less RAM in general and b) making sure progress gets preserved through crashes. (Both of which should be pretty simple.)

My memory usage bounces up and down wildly but it averages out to a slooooooow leak that eventually causes a crash. It’s very unpredictable (my game is complex and randomized) and can take several hours, so most players might not see it… but I’d love NOBODY to see it!

(Is a slow leak a side effect of using the malloc map at all? My long-run automated stress-testing is on the Simulator rather than the device. It’s harder to test slow leaks on the device.)

Thanks in advance!

1 Like
2

In addition to the .new -methods I'd look for curly braces. Whenever you write { }, you allocate a new table.

One common pitfall is string concatenation. Lua caches both the operands and the resulting string, meaning a simple on-screen timer can become a memory leak if you're not careful.

I'm not sure how smart the Lua GC actually is, but it might be that circular references don't get cleaned. Setting the references nil should remove any doubt.

1 Like
3

Thanks—two great tips!

I have tons of string concatenation, so I’ll look into what might be happening there. (From a little research, it looks like if I’m building a string in a loop, I might be better off building a table instead, converting it to a string one time at the end.)