I fixed crash bug in CCScheduler.cpp

cocos2d-x C++
#1

Hey all,

I wanted to share a subtle crash bug I found earlier this year. It was pretty nasty, and was appearing due to our use of the cocos particle system.

The problem is in two parts.
First, notice that in this function, there is call to free(element~~>entry), but the pointer is not set to NULL.
<pre>
void Scheduler::removeUpdateFromHash
{
tHashUpdateEntry **element = NULL;
HASH_FIND_INT;
if
{
// list entry
DL_DELETE;
free;
// element~~>entry = NULL; <————I ADDED THIS LINE!
// hash entry
Object* target = element~~>target;
HASH_DEL;
free;
// target#release should be the last one to prevent
// a possible double-free. eg: If the might want to remove it itself from there
target~~>release; <——— THIS CAN LEAD TO A CALL TO Scheduler::unscheduleUpdateForTarget
}
}
</pre>

Second, when target~~>release is called above, it can lead to a call to this function below. Notice that the pointer that was free’d above is now used with, “element~~>entry~~>markedForDeletion = true”.
<pre>
void Scheduler::unscheduleUpdateForTarget
{
if
{
return;
}
tHashUpdateEntry**element = NULL;
HASH_FIND_INT;
if
{
if
{
// if <————I ADDED THIS LINE!
element~~>entry~~>markedForDeletion = true;
}
else
{
this~~>removeUpdateFromHash(element->entry);
}
}
}

In short, a pointer that was deallocated is sometimes being used, leading to memory corruption.

I found and fixed this bug using cocos2d-2.1beta3-x-2.1.1.zip, but it looks like it still exists in the latest, cocos2d-x-3.0alpha0-pre.zip.

#2

@Mark Domowicz
Can you show the repeat steps.thanks.

#3

Hi WenHai Lin - Unfortunately, I don’t have an idealized test case. And without giving you the entire project, I don’t know how I can demonstrate the bug in a way that would be useful. All I can say really is that the problem occurred on program shut down, and was related to using the CCParticle and CCParticleSystemQuad systems.

I’m sure you can see how the problem arises though. If element->entry is deleted, but then used later, certainly this will cause memory problems. The lines I added above are a simple fix and definitely solved the problem for us.

Hopefully that helps!

#4

Thanks for your sharing very very much! , It’s really a potential bug!
Mark Domowicz wrote:

Hey all,
>
I wanted to share a subtle crash bug I found earlier this year. It was pretty nasty, and was appearing due to our use of the cocos particle system.
>
The problem is in two parts.
First, notice that in this function, there is call to free(element~~>entry), but the pointer is not set to NULL.
>
>
>
Second, when target~~>release() is called above, it can lead to a call to this function below. Notice that the pointer that was free()’d above is now used with, “element~~>entry~~>markedForDeletion = true”.
>
[…]
>
>
In short, a pointer that was deallocated is sometimes being used, leading to memory corruption.
>
I found and fixed this bug using cocos2d-2.1beta3-x-2.1.1.zip, but it looks like it still exists in the latest, cocos2d-x-3.0alpha0-pre.zip.