Win32 - XMLNode Access Violation on Release Crash

This problem has been causing the game to crash far too many times and I can’t seem to come up with a solution so any help would be appreciated. I’m using Cocos2dx 3.8 and Visual Studio 2013 for a Win32 (PC) debug & release versions.

When changing scenes and releasing sprites, very often I get the following error:

Unhandled exception at 0x1009CD11 (libcocos2d.dll) in Gataela.exe: 0xC0000005: Access violation reading location 0x0A1A0A34.

It crashes on the following block of code:

The call stack is as follows:

There’s no direct call I can see being made to that block of code because the line directly before it in the call stack is:

EmoteBubble::~EmoteBubble() { if (intro && intro->getReferenceCount()) { //animate intro->release(); } if (repeat && repeat->getReferenceCount()) { //animate repeat->release(); } if (prev && prev->getReferenceCount() > 0 && prev->getReferenceCount() < 200){ //crashing right here on the sprite prev->removeFromParent(); } }

The prev value before this is not null and is a valid pointer. I tried encasing both this section of code and the XMLNode code that crashed into a try-catch block but it wouldn’t trigger the catch portion of the block (even if I was trying to catch everything).

I also tried removing that line of code with the sprite (the prev portion) but it would crash later on in a different section with other Sprite objects.

It’s worth noting this error does not reoccur on iPad, Android, or Wintab and not every EmoteBubble object crashes here.

Thanks.

You generally do not need to care about the reference count of sprites as it is automatically handled by Node: when calling addChild(Node *child) and removeFromParent() the child is added into and removed from a Vector (Vector<Node*> _children), which is a class built upon std::vector that automatically retains objects when inserted into it and releases objects when erased from it.
Why are you checking the reference count of the objects? In theory for each retain that you call you should have a release, so those checks seem unnecessary.

Yes I know.

However the object that’s being removed has it’s sprite’s parents as a batch node for faster rendering. When the object is removed it’s sprite should be removed. The check for the reference count is in the case where the batch node has been removed. In that case you don’t want to remove the sprite from it’s parent because it’ll crash. The check for a ref count < 200 is to fix a weird behavior where the ref count was ridiculously high but not int_max.