Crash in Cocos on touch

Crash in Cocos on touch
0.0 0


we have some crashes directly in Cocos by touch. We dont have any steps to reproduce.

HTC Sensation Z710e
HTC Desire - 2.3.7
Desire HD - 2.3.5
Samsung GT-I9100 - 2.3.5

/cocos2dx/cocos2dx/platform/android/CCEGLView_android.cpp:112 (return m_pDelegate;)
/cocos2dx/cocos2dx/platform/android/jni/TouchesJni.cpp:66 (cocos2d::CCDirector::sharedDirector()->getOpenGLView()->getDelegate()->touchesBegan(&set, NULL):wink:

Looks like m_pDelegate doesnt exist.

Do you have somebody the same problem?



Thank you, #950 is created for it.


Ok, i dont think i fix it, most like i’ve changed some things back.
The call from touchesJNI in the end goes to the CCMenu class in the ccTouchBegan() method and,
after that in the itemForTouch method. In the last it use dinamic cast for casting CCObject object in to CCNode one:
@ CCNode* pChild = dynamic_cast<CCNode*>(pObject);@
and it looks like it succeded, but after it try to acces any member of casted instance it just goes down… probably execfault.
So it seems that Android got some issues with using RTTI in native code. So i just changed dynamic cast on to regular one:
@ CCNode* pChild = (CCNode*)pObject;@
Like it was in the previus version of that class(0.10.0).And its all work fine now.
And here is my question - Does dinamic cast gives some real performance benefits instead of regular object type casting?

Sorry for my bad english btw :slight_smile:


No, dynamic_cast has not performance benefit, but it is more safer.
It will return null if the pointer can not be translated to a specific type.


Thanks for your answer Minggo :slight_smile:

In that case, it is realy some kind of NDK issue, becouse i’ve checked that and in this case:
CCNode* pChild = dynamic_cast<CCNode*>(pObject);

pObject is not null, it does contain pointer. But i think that danvik does not allowed access to , such way, dinamically memory allocated object. And thats why when we try to acces this object we got whis “silent” crash. I may be wrong offcource.

And what will be the final solution? will it be changed back w/o dynamic_cast, or may be there is some way to make it work with it?

P.S. Just now i’ve read intresting thing in cplusplus documentation of NDK:

II.3. Static runtimes:


Please keep in mind that the static library variant of a given C*+ runtime
What this means is that if your project consists of a single shared
library, you can link against, e.g., stlport_static, and everything will
work correctly.
On the other hand, if you have two shared libraries in your project
which both link against the same static
runtime, each one of them will include a copy of the runtime’s code in
its final binary image. This is problematic because certain global
variables used/provided internally by the runtime are duplicated.
This is likely to result in code that doesn’t work correctly, for example:

  • memory allocated in one library, and freed in the other would leak
    or even corrupt the heap.
  • exceptions raised in cannot be caught in .
  • the buffering of cout not working properly
    This problem also happens if you want to link an executable and a shared
    library to the same static library.
    In other words, if your project requires several shared library modules,
    then use the shared library variant of your C*+ runtime.

It looks like we have a secont type of error when exceptions raised in cannot be caught in
but after i’ve tryed to change APP_STL := stlport_static to APP_STL := stlport_shared in and recompile it i’ve got crash on application startup. My skills are not enouth to understand it , so any help will appreciate :wink:


Similar to my problem

Try APP_STL := gnustl_static


Thank you Serg, its working that way!)
But, as matched in your topic it is have some licence differens. It’s doesnt metter realy for me now, but it’ll be nice to know the difference.


I would also like to know the difference


I would also like to know the difference


gnustl_static causes static linkage against the libstdc*+ library. The library is licensed under GPLV3 with a runtime library exception clause*+/manual/license.html

stlport uses a non-GPL license: that is very permissive, open, and simple to understand.

Most companies avoid GPL licensed products for a host of reasons. Those reasons include 1) It’s not clear if the runtime library exception applies to static linking and 2) it’s not clear if the license requires your game code to be open source if it is statically linked.

So using gnustl_static is not an option for companies wishing to avoid legal problems.


I also have the crahs in itemForTouch (NDK r7). I had other problems when using gnustl, such as crash with std::string. I tried to group everything in one library (one single .so) and it’s not better. I will probably revert the RTTI locally. I don’t see any advantage to using it.