Spine Cocos2dx is causing sever memory leak.

apple · 30 يناير 2017

Hello all,
Our game has loads of spine animations and they are causing sever memory leaks and game crashes like in 5 secs (memory goes up to 1.5 gb (ram usage on iphone 6s Plus device and same happens on android)). We are using Cocos2dx 3.10 - 3.14.1, and we checked it with API provided by esoteric software and not that is shipped by cocos2dx it self. I am patching your example code right now, cocos2dx is taking loads of time to download using your commands.

The way we are using your API is by just replacing the files you have provided with the old file that is shipped with cocos2dx. We used file from spine-c/spine-c (both src and include) and spine-cocos2dx/src/spine. All animations works fantastic except for memory leak issue.

But People Using API Shipped with cocos2dx are facing same issue as well. I have checked with them on cocos2dx forum.

Scenario

We have 2 scenes. Our game starts at scene1, scene1 has loads of spine animation and scene2 currently don't have any animation. When we arrive at scene1 game works fine with no memory leak. When we go to scene2 still no memory leak happens. When we go back from scene2 to scene1 than all animations are loaded again and it now that memory leaks occurs. We are implementing the animations as you guys are doing it in BatchingExample in cocos2dx example. Like making skeletondata and than using that skeletondata in SkeletonAnimation* and when replacing scene we dispose everything (atlas, sekeloton data and etc as you guys are doing) in destructor method of the scene1. Even when copying your code still memory leak occur.

Also some files cause memory leak even without scene replacing. These file are big in .json and .png. Meaning they have loads of animations and spine character is big.

But I have also tested with binary data file and issue is same.

Also please explain me what is the purpose of scheduleUpdate(); and why it is being used in every example.

We have professional spine license and will really appreciate if you guys can help us.

thanks

sorry sever is severe,
and we are using "spine":"3.5.46" to export related file.

Jjpoag · 30 يناير 2017

Greetings!

I'm in now way associated with Spine or Esoteric, but...

My team has strict rules about memory leaks and memory tracking and we use a custom memory tracker as well as several other commercial trackers. I've written a memory leak detector that's now a part of the Spine-C Unit testing. Check out spine-c/spine-c-unit-tests/memory for more details.

The leaks that I've found have been plugged, and were in the KB range, not GB.

Blind bleeding the blind
The first step is to determine what is leaking. XCode has instruments, which I find extremely useful for tracking leaks:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html

This should catch most C/C++/Objective-C code leaks including bad ARC usage.

However, OpenGL ES leaks can be quite devastating too. Make sure that the texture objects are being freed correctly:
https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ToolsOverview/ToolsOverview.html#//apple_ref/doc/uid/TP40008793-A2

Unpacked RGBA surfaces that conform to POW2 requirements take up a lot of space. A simple 1024x768 image sits on a 1024x1204 texture and takes up 4 MB. (3MB on RGB 24 bit surface). If I were leaking Gigs, textures would be my first bet.

Stop the Open GL frame on the second scene and inspect ALL objects to see if scene 1 is still hanging around.

The blame game
Once you figure out what is leaking, you can track down who is leaking it. First, inspect and trace the entire lifetime of the object to see if there is some sort of leak. Check Destructors, Move and Copy Constructors, SmartPointers (for atomic access violations), etc... Also, I think Cocos2dx has a texture cache. Make sure that it's getting hit for the same texture and that garbage collecting is working.

A little research shows that Cocos2dx does have memory leak issues. One thread points to GLFW as the culprit.

Memory is the cause and solution to all my problems
Sometimes memory leaks are grouped together around a single object. You might leak several objects and only solving the leak of a single object will take care of the rest.

Also, check that crash. There might be an infinite loop allocating memory...

Throw a debug break point before changing back to scene 1 and walk through until you get the crash. Use stepping and break points to zero in on the exact crash point. (I use something like a binary search by dividing code sections in half)

Mario · 31 يناير 2017

Thanks jpoag for the extensive reply!

apple, could you provide a sample application that demonstrates the leak? Modifying the example will do. I'm sorry that that involves downloading cocos2dx, not much we can do about. Putting it in the git repository is a no go.

apple · 31 يناير 2017

Hello ,

Thanks gents for replying. I have been working on it all night, so I have figured out the issue and corrected and it was a mistake on our part.

In scene1 before calling
auto director = Director::getInstance();
director->replaceScene(Scene);

I was calling
this->getEventDispatcher()->removeAllEventListeners();

Calling removeAllEventListeners(); before replaceScene in a scene that has spine animations cause extreme memory leaks. I did not knew about it. Now we are removing event listeners by name and every thing works fine.

Just out of interest: why do calling removeAllEventListeners(); cause memory leak?

Thanks

Mario · 1 فبراير 2017

Great you found the issue! I'm honestly not sure why removing the event listeners from the event dispatcher like that would cause a memory leak.