Assert failed: Node still marked as running on node destruction! Was base class onExit() called in derived class onExit() implementations?

Assert failed: Node still marked as running on node destruction! Was base class onExit() called in derived class onExit() implementations?
0

#1

Im trying to create Mensch game, here is some of my codes
but sometimes when I try to run it, I face this error:

Assert failed: Node still marked as running on node destruction! Was base class onExit() called in derived class onExit() implementations?

I didn’t delete any child or parents! and I don’t know what is happening! and I don’t know why it works sometimes without any errors. should different kind of sprites be on different layers? I mean should I put the back Ground on one layer and put other sprites on other layers !?


#2

No. The error is suggesting that you’re not calling the base class’s function in an overridden function. From the code you posted, I see one instance of this. In Game::onEnterTransitionDidFinish() you should add:

CCLayer::onEnterTransitionDidFinish();

In Game you’re not overriding onExit as the error suggests, but perhaps you are in one of the other classes, like MainMenu or GameOver?


#3

Thanks a lot, I think my problem is solved.
I am using cocos2d-x v3.0 and its new container cocos2d::Vector, should I release it in onExit() ?
I know that using CCArray requires retaining and releasing, what about Vector?
Generally speaking, what should I do in onExit()?


#4

The cocos2d::Vector class is not derived from cocos2d::Ref, so it does not have the retain(), release(), and autorelease() functions. I think strictly speaking, you don’t need to do anything with the Vectors, as their destructors call the clear() function.

I don’t always override onExit. When I do, I usually use it to unload any sound effects that the layer loaded, remove sprite sheets that the layer added, and stuff like that.


#5

Still getting this same problem just now. Using cocos2d v3.6 - through RapidGame. I looked all over but I should not have any forgotten calls to superclass onExit or similar.


#6

Btw, the phrasing leaves it totally unclear whether the question is trying to convey that one must call the base class implementation, or whether one must not do so. Even though I know CC I initially understood it as “don’t call the base class onExit”.


#7

Dear all,

I just resolve MY PROBLEM which leads to this same assertion (“Node still marked as running on node destruction! Was base class onExit()…”), and I wanted here to post my contribution in case where somebody did the same mistake as me… Because YES, I made a small mistake, but it caused a very BIG and hard to resolve problem :tired_face:! Let me explain :slight_smile:

Somewhere in my code I did this mistake : I created a cocos2d-x object with a classic static create method, and then, since finally I did not need it, I delete it : like that

  	Button* but = Button::create(frame, "", "", TextureResType::PLIST);
	but->addClickEventListener(CC_CALLBACK_1(SelectableElementsGrid::menuItemSelected, this));
	but->setZoomScale(0.2f);
	but->setLayoutParameter(_buttonsLPParameter);
	if (_currentLine == nullptr ||
		_currentLine->canAdd(but, _selectionBorderSize) == false)
	{
		if (addLine(but->getContentSize()) == false)
		{
			delete but;   // HERE IS MY MISTAKE !!!!!
			return false;
		}
	}

The result of that is that the memory zone occupied by my but pointer is freed, OK… But the problem is that the pointer is still in the AutoreleasePool _managedObjectArray list (the list of objects the cocos2d-x library internally evaluate periodically to see what must be auto-released because no longer used).
But it does not explain why it causes the assertion we talk about… In fact, later in my code, I create many other ui::Button and it is very strange but one of them takes exactly the same adress then the previous one ! So it is added 2 times in the AutoreleasePool list :cry:! As a result, when auto-release is done by the AutoreleasePool instance of cocos2d-x application, this pointer is released 2 times and since I used the second button in my application, it is still added in its parent when the release is done the second time… And so, _running boolean is still true, causing the assertion :sob::sob:

Arrrrrrrrg ! that was very difficult to debug… I was oblized to add code in the AutoreleasePool implementation to see that my pointer was 2 times in the list !

I hope this will help somebody since I spent one day on that “simple” problem :scream:

See yaa my friends :sunglasses:


#8

I was adding an istance of a node-derived class to a scene.
I had the same issue. I think that you should allocate the istance dinamically using a pointer and new

MyNodeDerivedClass * obj = new MyNodeDerivedClass;
//set obj texture and position
this->addChild(obj);

in this way the instance is not destroyd but you have to manage the deallocation

I hope that this helps

MandarX