Memory leaks on master

hcabral

Hi folks,

I've recently took the latest commit a736a79 for a spin, to check if I could ship with it, and sadly it seems to have lots of memory issues. My app, who does run on the bleeding edge due to large textures, started crashed again.

Here's v2.0.1:

Memory in use (in bytes): 146104320
Memory in use (in bytes): 163307520
Memory in use (in bytes): 177545216
Memory in use (in bytes): 194490368
Memory in use (in bytes): 211812352
Memory in use (in bytes): 161734656
Memory in use (in bytes): 178974720
Memory in use (in bytes): 196022272
Memory in use (in bytes): 230166528
Memory in use (in bytes): 247107584
Memory in use (in bytes): 214347776

The app peaks at around 250MB and they goes all the way up to 320MB sometimes, be it cools down after a while. This is an iPad Mini Retina, by the way.

Here's with the latest:

Memory in use (in bytes): 190689280
Memory in use (in bytes): 191488000
Memory in use (in bytes): 208203776
Memory in use (in bytes): 205975552
Memory in use (in bytes): 224026624
Memory in use (in bytes): 254783488
Memory in use (in bytes): 204595200
Memory in use (in bytes): 188035072
Memory in use (in bytes): 221827072
Memory in use (in bytes): 222044160
Memory in use (in bytes): 238956544
Memory in use (in bytes): 271351808
Memory in use (in bytes): 286478336

And then it crashed. One can see that the overall footprint is bigger. Have you guys been trying the latest version and ran tests like this?

Cheers,
Henrique

Daniel

Thanks for the heads-up! I just profiled the latest version, and indeed: there was a memory leak caused by the "[SPTexture loadFromURL:...]" method -- with quite a big effect, because every texture would be in memory twice. Oooops! 😳

Are you using that method somewhere? That would explain the memory leak then. I've just pushed a fix to the master branch. Please let me know if that works for you!

hcabral

Daniel, I'm not using that specific method. My app uses ARC and I'm suffering the consequences, i.e., the app will crash if the user changes the scenes too fast, not allowing ARC to free the memory. In other words, as far as I can tell, no retain cycles, and the texture release method works fine (hence the memory variation).

I will continue testing, will try to reduce some textures and will also consider changing my app to MRC.

Thanks for the update!

Daniel

Hm, very odd! Definitely try the "Leaks" Instrument in Xcode (Product - Profile - Leaks). It is a huge help in that respect!

hcabral

Daniel, I've done it many times. Using ARC, though, Instruments will not detect retain cycles, for example, which were my problem initially in this project. Any reference to "self", where "self" is an SPSprite where stuff is put on top of it caused huge retain cycles, memory would just explode.

All in all, my memory is well managed. ARC, though, is not super fast and sometimes behaves like a garbage collector. I have a special situation in my code where 3 consecutive scenes have texture atlases sized 4096x4096 pixels for retina iPads. =/ I only keep the current (_67MB) and the next (+ _67MB) in memory. However, when going from A-to-B-to-C, I will release A textures, and eventually B textures, but I can tell by the profile that it takes too long for ARC to kick in and while loading D textures in the background of C, the app will crash due to lack of memory.

I've managed to gain some memory by changing how sound is executed/played, and now the app is working on the iPad Mini Retina. In the bigger iPads it works fine.

Cheers!

Daniel

Thanks for the update! Damn, you're right, I forgot that the "Leaks" instrument won't catch retain cycles.