Doable CCParticleSystem Leak – C++

I’ve seen that Cocos2d’s ParticleSystem makes use of image->launch() in initWithDictionary methodology. CCImage is just not an autoreleased object and I believe C++’s delete needs to be used as an alternative of releasing it. I’ve checked out cocos v4 and v3 and this hasn’t been modified. I added the code snippet from CCParticleSystem.cpp. I’ve checked the reminiscence leaks with Ref::printLeaks methodology.

// For android, we must always retain it in VolatileTexture::addImage which invoked in Director::getInstance()->getTextureCache()->addUIImage()
picture = new (std::nothrow) Picture();
bool isOK = image->initWithImageData(deflated, deflatedLen);
CCASSERT(isOK, "CCParticleSystem: error init picture with Knowledge");
CC_BREAK_IF(!isOK);
  
setTexture(Director::getInstance()->getTextureCache()->addImage(picture, _plistFile + textureName));

image->launch();

Have you ever debugged it to confirm?

In that particular space of code, the Picture is created, used, and launched, and because it ought to have a reference rely of 1, it will likely be deleted.

I debugged this code once more and I noticed that it provides the picture to VolatileTextureMgr and it will increase the reference rely by one. Once I debug with printLeaks, it wasn’t deallocating the pictures that are retained by VolatileTexture after some time and the picture rely was over 1000. Does it deallocate the pictures mechanically in regular situations?

When the picture is added to VolatileTexture, it will increase its reference rely by 1 by way of a name to retain(), however it additionally releases it within the destructor:

VolatileTexture::~VolatileTexture()
{
    CC_SAFE_RELEASE(_uiImage);
}

It’s nonetheless right.

The sequence of occasions is as follows:

Picture is created in particle system
Picture refCount = 1
Picture added to VolatileTextureMgr, wrapped in a VolatileTexture, so now refCount = 2
Picture is launched in particle system, so refCount = 1

Sooner or later the occasion of the VolatileTexture will likely be freed, and in its destructor it calls launch() on the picture. refCount = 1 at this level, so that is what occurs:

void Ref::launch()
{
    CCASSERT(_referenceCount > 0, "reference rely needs to be higher than 0");
    --_referenceCount;

    if (_referenceCount == 0)
    {
        ....
        delete this;
    }
}

So, it does delete itself.

I’m unsure how VolatileTextureMgr works, or when it deletes textures and such, however simply going off the code, there is no such thing as a difficulty within the ParticleSystem. If there’s any form of drawback, it’s almost definitely within the VolatileTextureMgr or the best way it’s used.