• Advertisement
Sign in to follow this  

Premature destruction of object in Android

This topic is 1778 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts



Until yesterday I used an older version of AngelScript, from around June 2012 and everything worked fine for my purpose. All scripts ran consistently in android + desktop systems, as far as i was concerned. However, I needed the ability to make nested function calls, and therefore needed the new Push/Pop State functionality. 


I did the update in today's morning to the latest version of angelscript, put it to run pretty much the same way I used to before but a obscure bug has been introduced. I've tried everything and I can't solve it.


I have a custom type named UIButton, which is a banal ref type, meant to be created and managed by scripts. As I always did, I have a UIButton button; declared globally in a script, which works fine in windows. It is instanced with the context and only destroyed when i release the context at shutdown.


Nevertheless, against the previous behavior, while I run the same script in android, it crashes my process because button is not valid in any time. I wrapped some logs around the ResetGlobalVars function and in the UIButton constructor and destructor, and here's the output:


-> Going to initialize global vars

-> UIButton created

-> UIButton destroyed

-> Finished initializing global vars


As you can see, within the call of ResetGlobalVars, the button is both created and destroyed. I have even tried to call this function several times in a row and the log is always the same, the UIButton instance doesn't stay alive no matter what, in android.


About compilation of the library, for windows it was compiled as-is, changing only the runtime to Multithreaded (Debug) DLL . For android its the same deal,but added AS_MAX_COMPATIBILITY so the generic calls are used. (couldn't make the .S arm code compile yet).


Any help is appreciated, I need to solve this as soon as possible. Granting a safe sandbox environment from scripts is essential to my software.


Bonus Question: Is it possible to avoid crashes when calling a method on a null reference? Thanks



And to the writer of the library, amazing job, its great beyond words, expect to see it in a pretty cool project soon! :))

Share this post

Link to post
Share on other sites

At first I suspected that a change in as_callfunc_arm.cpp might have caused this bug, but you say you're using AS_MAX_PORTABILITY so that can't be the reason.


Does the same problem happen if you compile the library with AS_MAX_PORTABILITY on Windows?


How has the global variable been declared in the script? Is it just a declaration without any specific initialization, e.g. 'UIButton button;'? The bytecode sequence for that would look like this:



    0   1 *    SUSPEND
    1   1 *    CALLSYS  31           (UIButton@ _beh_2_())         // call factory function
    3   1 *    STOREOBJ v1                                                       // store handle in local variable
    4   1 *    PshVPtr  v1                                                            // push the pointer in the variable onto the stack
    5   2 *    PGA      10833368                                                 // push the address of the global variable on the stack
    7   3 *    REFCPY   0x3e6f78                                               // copy the handle to global variable, and increase the reference
    9   2 *    PopPtr                                                                    // remove the top pointer from the stack
   10   1 *    FREE     v1, 4091768                                            // release the handle in the local variable
   12   1 *    RET      0


Can you add log messages in the AddRef and Release behaviours so we can see if they are called as they should?


Unfortunately I do not have a development environment for Android to test this on, so I'll need your help in figuring out the problem.

Edited by Andreas Jonsson

Share this post

Link to post
Share on other sites

So I updated my Android compiler environment and tried again with it, and verified it still happened.


Now about the resolution, I will test those things and get back to you next.


RIght now, I managed to compile angelscript for android ndk without AS_MAX_PORTABILITY, for the ARM architecture and im experimenting with this, but im having trouble.

In android, using native calls instead of generic ones causes crashes whenever i call something from the scripts.


script: test.as


void test()


   int i = 0; i += 5; // primitive operations work fine and the test() function ends normally without crash


   Vec2f position; // crashes the program

   print("hello world"); //crashes the program



As you can read from the comments, the script function compiles and executes fine, primitive operations work, but nothing i exported runs. even a simple stub global function that I export with asCALL_CDECL will crash the program. Is this a bug with ARM native calls?

Share this post

Link to post
Share on other sites

Now, answering to your reply:


I tried AS_MAX_PORTABILITY in windows, and the same bug is reproduced exactly the same way. However, I use aswrappedcall and the factory/add/release functions are the same for either native and generic conventions.


I logged the ref behaviors and there is something weird happening:


=> Before ResetGlobalVars


=> [RefCounter:057265A4]: Init with reference counter at 1

=> [RefCounter:05726700]: Init with reference counter at 1


=> UIButton Constructor

=> [RefCounter:05726598]: Reference added: Now 1

=> [RefCounter:05726598]: Reference removed: Now 0 (Releasing)

=> UIButton Destructor


=> After ResetGlobalVars


This is very weird. First, there are two inits and I don't know where they come from, I only have one global variable, UIButton button; declared outside any function. 

Then, its mem address doesnt match the later one (unless this is normal with polymorphism? )

Finnaly, there is a AddRef call that puts the ref counter at 1, which is impossible since it begins at 1, and if it ever reaches 0, it releases..


Could this be something wrong with my constructors? They are declared in the plain old way "Constructor()", the constructor chain is: UIButton() calls UIControl() which calls RefCountable().


The destructor in RefCountable is declared virtual.. The UIButton is properly initialized in the constructor, the ref count goes to 1, then somehow it is 0, when addRef is called on the exact same address.. This didn't happen with the build of angelscript i had before..

Edited by Grimshaw

Share this post

Link to post
Share on other sites

Let's leave the native calling conventions on Android to the side for a while. I suspect this could be just a problem with the as_config.h, but it may very well be caused by the problem you're having with AS_MAX_PORTABILITY, so let's concentrate on the problem with AS_MAX_PORTABILITY first.



That the problem with AS_MAX_PORTABILITY happens on Windows as well makes it easier, as I should be able to reproduce the problem.


The logging you added definitely looks weird, but I need further information from you.


What does the factory function, addref and release functions look like in your UIButton class? Can you show the code? Can you show the actual code you use to register them with AngelScript?


You seem to be using inheritance to implement the reference counting. Is the UIButton inheriting from multiple parent classes? Does any of the parent classes inherit from multiple parent classes?



Finally, would it be possible for you to write a small example to reproduce the problem in an isolated way?

Share this post

Link to post
Share on other sites

I dont have an easy way to have an isolated and complete example to reproduce this, as all the code is intrincate within my engine, but I can help with all you said:



// All-purpose default constructor factory
template<typename T>
T* genericFactory()
cout<<"instancing ref type"<<endl;
return new T();

/// Adds a reference
void RefCountable::addReference(){
cout<<"[RefCount:"<<this<<"] Add: "<<refCount <<endl;

/// Removes a reference and destroys if necessary
void RefCountable::removeReference(){
cout<<"[RefCount:"<<this<<"] Released: "<<refCount - 1<<endl; 
if(--refCount == 0){
delete this;
 engine->getASEngine()->RegisterObjectType("UIButton", sizeof(UIButton), asOBJ_REF);


engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_FACTORY, "UIButton@ f()", WRAP_FN(genericFactory<UIButton>), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_ADDREF, "void f()", WRAP_MFN(UIButton, addReference), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_RELEASE, "void f()", WRAP_MFN(UIButton, removeReference), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_IMPLICIT_REF_CAST, "UIControl@ f()", WRAP_OBJ_LAST(UIButtonRefCast), asCALL_GENERIC);

  engine->getASEngine()->RegisterObjectMethod("UIButton", "void bindSignal(const string &in, Slot@)", WRAP_MFN(UIButton, bindSignal), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectMethod("UIButton", "void setPosition(float,float)", WRAP_MFN(UIButton, setPosition), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectMethod("UIButton", "void setSize(float,float)", WRAP_MFN(UIButton, setSize), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectMethod("UIButton", "void setLabel(const string &in)", WRAP_MFN(UIButton, setLabel), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectMethod("UIButton", "void setProperty(const string &in, const string &in)", WRAP_MFN(UIButton, setRawProperty), asCALL_GENERIC);



About inheritance:


UIButton -> UIControl

UIControl -> Animable, sigc::Trackable, RefCountable


All constructors are chained properly.


This behavior is very weird. For one call to genericFactory(), RefCountable constructor is called 4 times in different addresses. And we are only talking about 1 global variable.



Edited by Grimshaw

Share this post

Link to post
Share on other sites

Does Animable or sigc::Trackable also inherit from RefCountable? This is the only way I can think of for the RefCountable constructor being called multiple times at different addresses.


I assume the constructor of RefCountable initializes the refCount to 1. Is this correct?


The methods addReference and removeReference are declared as virtual in the RefCountable class, aren't they?

Share this post

Link to post
Share on other sites

Animable and sigc::Trackable do NOT inherit RefCountable.


And yes, the constructor of RefCountable inits at 1 (pretty much as described in your docs)


addReference and removeReference are just plain methods, not virtual. I figured that their behavior is fixed so there is no point in making them virtual..

Share this post

Link to post
Share on other sites

I wonder if it is not the templates in the autowrappers that are playing tricks on us.


Can you try with a manual implementation of the wrappers?



void Wrap_UIButton_factory(asIScriptGeneric *gen)
   *reinterpret_cast<UIButton**>(gen->GetAddressOfReturnLocation()) = new UIButton();
void Wrap_UIButton_addReference(asIScriptGeneric *gen)
void Wrap_UIButton_removeReference(asIScriptGeneric *gen)
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_FACTORY, "UIButton@ f()", asFUNCTION(Wrap_UIButton_factory), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_ADDREF, "void f()",  asFUNCTION(Wrap_UIButton_addReference), asCALL_GENERIC);
engine->getASEngine()->RegisterObjectBehaviour("UIButton", asBEHAVE_RELEASE, "void f()",  asFUNCTION(Wrap_UIButton_removeReference), asCALL_GENERIC);

Edited by Andreas Jonsson

Share this post

Link to post
Share on other sites

What if I told you that solved the problem? RAGE MODE: ON! :))


Thanks a lot for the patience, that actually solved the problem as it runs now in android and windows as well, guess I ll have to refactor the remaining types, unless you have a more elegant solution?


Now that problem 1 is solved (bogus, I still dont know why!), can you tell me if it is possible to protect null handles? That when someone does UIButton@ button; and calls a method on it, the whole program doesnt crash?


And to finalize, any tips on the ARM issue? Everything seems to be allright with the library, but at the first attempt to call a native function in android it crashes the hell out. Do I benefit from these native calls or generic is just enough? I wonder.


Thanks again!

Share this post

Link to post
Share on other sites

OK. Well, at least we've narrowed down the problem to the templates and there is a work around. I still have to reproduce this problem so I can find the problem in the templates. I may ask you for some help in that later on as I get a chance to really sit down and work on this.


Rather than manually implementing all the generic wrapper functions (at least until I can have the autowrappers, or the native calling conventions working) you may want to try the previous version of the autowrappers. That implementation was slightly less complex and may thus work better. 





The app shouldn't crash when the script attempts to call a method on a null handle. The context should raise a script exception in this situation which will make Execute() return with the return code asEXECUTION_EXCEPTION. You'll need to handle this return code, and you'll probably want to log some info about it (See helper add-on function PrintException() for tips on how to do that). Are you handling the return code from Execute(), or is the crash happening before Execute() returns? 





And about the native calling conventions on ARM. Can you find out which defines that are provided by default in the compiler, so I can see if the as_config.h is correct? I'm not sure what compiler you use, but with gnuc, you can get this list with the following command: echo . | g++ -dM -E -

Share this post

Link to post
Share on other sites

So, two ot of three issues solved, thanks!


About the ARM now, here is the compilation command of one source file from angelscript, compiling the ARM version for the NDK.



"Compile++ thumb : angelscript <= as_scriptengine.cpp
K:/NDK8/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-g++ -MMD -MP -MF ./obj/local/armeabi/objs/angelscript/as_scriptengine.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -no-canonical-prefixes -march=armv5te -mtune=xscale -msoft-float -fexceptions -fno-rtti -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -IK:/NDK8/sources/cxx-stl/system/include -Ijni/../../../source -DANDROID  -Wa,--noexecstack      -IK:/NDK8/platforms/android-9/arch-arm/usr/include -c  jni/../../../source/as_scriptengine.cpp -o ./obj/local/armeabi/objs/angelscript/as_scriptengine.o 

About the defines:



#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 65535
#define __FLT_MIN__ 1.1754943508222875e-38F
#define __UINT_LEAST8_TYPE__ unsigned char
#define __INTMAX_C(c) c ## LL
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 255
#define __ANDROID__ 1
#define __WINT_MAX__ 4294967295U
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 4294967295U
#define __WCHAR_MAX__ 4294967295U
#define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L)
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define __UINT_FAST64_MAX__ 18446744073709551615ULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __ARMEL__ 1
#define __GNUC_PATCHLEVEL__ 0
#define __UINT_FAST8_MAX__ 255
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __UINT_LEAST64_MAX__ 18446744073709551615ULL
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __ARM_ARCH_5TE__ 1
#define __UINT_LEAST8_MAX__ 255
#define __UINTMAX_TYPE__ long long unsigned int
#define __linux 1
#define __DEC32_EPSILON__ 1E-6DF
#define __CHAR_UNSIGNED__ 1
#define __UINT32_MAX__ 4294967295U
#define __LDBL_MAX_EXP__ 1024
#define __WINT_MIN__ 0U
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __WCHAR_MIN__ 0U
#define __INT64_C(c) c ## LL
#define __DBL_DIG__ 15
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define __USER_LABEL_PREFIX__ 
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.1920928955078125e-7F
#define __APCS_32__ 1
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __DEC32_MAX__ 9.999999E96DF
#define __INT32_MAX__ 2147483647
#define __SIZEOF_LONG__ 4
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 17
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 8
#define __DBL_MAX__ ((double)1.7976931348623157e+308L)
#define __INT_FAST32_MAX__ 2147483647
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __THUMB_INTERWORK__ 1
#define __INT_FAST16_TYPE__ int
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __INT_LEAST32_MAX__ 2147483647
#define __ARM_PCS 1
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __PTRDIFF_MAX__ 2147483647
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __GXX_ABI_VERSION 1002
#define __SOFTFP__ 1
#define __FLT_MIN_EXP__ (-125)
#define __INT_FAST64_TYPE__ long long int
#define __DBL_MIN__ ((double)2.2250738585072014e-308L)
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__ 
#define __UINT16_MAX__ 65535
#define __DBL_HAS_DENORM__ 1
#define __UINT8_TYPE__ unsigned char
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.6 20120106 (prerelease)"
#define __UINT64_C(c) c ## ULL
#define __INT32_C(c) c
#define __DEC64_EPSILON__ 1E-15DD
#define __ORDER_PDP_ENDIAN__ 3412
#define __DEC128_MIN_EXP__ (-6142)
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define unix 1
#define __INT16_MAX__ 32767
#define __SIZE_TYPE__ unsigned int
#define __UINT64_MAX__ 18446744073709551615ULL
#define __INT8_TYPE__ signed char
#define __ELF__ 1
#define __FLT_RADIX__ 2
#define __INT_LEAST16_TYPE__ short int
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __UINTMAX_C(c) c ## ULL
#define __SIG_ATOMIC_MAX__ 2147483647
#define __VFP_FP__ 1
#define __SIZEOF_PTRDIFF_T__ 4
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __INT_FAST16_MAX__ 2147483647
#define __UINT_FAST32_MAX__ 4294967295U
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __unix 1
#define __UINT_FAST16_TYPE__ unsigned int
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __CHAR16_TYPE__ short unsigned int
#define __INT_LEAST16_MAX__ 32767
#define __DEC64_MANT_DIG__ 16
#define __INT64_MAX__ 9223372036854775807LL
#define __UINT_LEAST32_MAX__ 4294967295U
#define __INT_LEAST64_TYPE__ long long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __DEC32_MAX_EXP__ 97
#define __INT_FAST8_MAX__ 127
#define __INTPTR_MAX__ 2147483647
#define linux 1
#define __LDBL_MANT_DIG__ 53
#define __DBL_HAS_QUIET_NAN__ 1
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __INTPTR_TYPE__ int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ unsigned int
#define __SIZEOF_FLOAT__ 4
#define __pic__ 1
#define __UINTPTR_MAX__ 4294967295U
#define __DEC64_MIN_EXP__ (-382)
#define __INT_FAST64_MAX__ 9223372036854775807LL
#define __FLT_DIG__ 6
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT_MAX__ 2147483647
#define __INT64_TYPE__ long long int
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __INT_LEAST64_MAX__ 9223372036854775807LL
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __LDBL_MIN_EXP__ (-1021)
#define __arm__ 1
#define __INT_LEAST8_MAX__ 127
#define __LDBL_MAX_10_EXP__ 308
#define __DBL_EPSILON__ ((double)2.2204460492503131e-16L)
#define __UINT8_C(c) c
#define __INT_LEAST32_TYPE__ int
#define __SIZEOF_WCHAR_T__ 4
#define __UINT64_TYPE__ long long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __DBL_DECIMAL_DIG__ 17
#define __DEC_EVAL_METHOD__ 2
#define __ORDER_BIG_ENDIAN__ 4321
#define __UINT32_C(c) c ## U
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.4012984643248171e-45F
#define __INT8_MAX__ 127
#define __PIC__ 1
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.4028234663852886e+38F
#define __INT32_TYPE__ int
#define __SIZEOF_DOUBLE__ 8
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define __DEC128_MAX_EXP__ 6145
#define __GNUC_MINOR__ 6
#define __UINTMAX_MAX__ 18446744073709551615ULL
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __INT16_C(c) c
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __UINT32_TYPE__ unsigned int
#define __UINTPTR_TYPE__ unsigned int
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __ARM_EABI__ 1
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-307)
#define __SIZEOF_LONG_LONG__ 8
#define __LDBL_DIG__ 15
#define __FLT_DECIMAL_DIG__ 9
#define __UINT_FAST16_MAX__ 4294967295U
#define __GNUC_GNU_INLINE__ 1
#define __UINT_FAST8_TYPE__ unsigned char
#define __ARM_FEATURE_DSP 1

Hope it helps..

Share this post

Link to post
Share on other sites

I see that the defines include both __ANDROID__ and __linux__. This is probably what's causing the problems you're seeing. With the latest release I added support for native calling conventions on Linux with arm. I wasn't aware that the define __linux__ was present on Android too, so now the code in as_callfunc_arm.cpp and as_callfunc_arm_gcc.S is mostly likely compiled incorrectly.


I'll review the defines that I use in as_config.h, as_callfunc_arm.cpp and as_callfunc_arm_gcc.S to have this fixed.

Share this post

Link to post
Share on other sites

The native calling conventions should be working again on Android with revision 1586.


I wasn't able to reproduce the problem with the autowrappers. Perhaps it is something compiler specific. What compiler did you use when you reproduced the problem on Windows?

Share this post

Link to post
Share on other sites

I recompiled the ARM version from the new revision and it doesn't seem to be working. Now it seems less like a crash and more like a sudden process halt down without even logging the stack frame. 


I think I didn't do anything wrong..




void testP()
r = asEngine->RegisterGlobalFunction("void testP()", asFUNCTION(testP), asCALL_CDECL);


How big is the improvement switching from generics to ARM instructions?

I am compiling for android with the latest NDK and for windows with visual studio 2010, the default compiler..

then from the script, calling testP() results in process death.


Does angelscript need RTTI? dynamic_cast anywhere?

Edited by Grimshaw

Share this post

Link to post
Share on other sites

Would it be possible for you to debug the code to see exactly where it fails inside the library when running on Android?


Did you use the earlier version of AngelScript from 2012 on Android? Or is this the first time you started using it on Android?



I can't say how big the improvement will be with using native calling conventions. I can't even say there will be an improvement, as it is quite likely the setup that has to be done in as_callfunc_arm.cpp give a higher overhead than the generic calling convention do.



AngelScript doesn't rely on RTTI. There are no dynamic_casts in the code.



I'll see if I can reproduce the problem with the autowrappers on msvc2010. I'm currently running using msvc2012, but I have 2010 on another machine.

Share this post

Link to post
Share on other sites

Not even with msvc2010 could I reproduce the problem with the autowrappers. There is probably something very specific about the classes you have that triggers the problem in the templates.

Share this post

Link to post
Share on other sites

I would love to debug the code to see what is wrong, but to be honest, debugging in android is far from ideal. Most people say it sucks beyond sanity and well, it seems to be true..


I am kind of weaponless when it comes to debugging in android, I am not sure what to do, but I will gladly follow your tips if you have any. In the meanwhile I will google a bit..


About the angelscript library, I used the previous one on android and ios and windows and everywhere else and all worked fine.. The only thing that is first time is aiming for ARM code by removing AS_MAX_PORTABILITY flag.


Thanks for all the other answers! I will give feedback about the bug if I come into more information. And for now I will keep the work going with generic calls..



EDIT: Yes, this problem seems to be specific to my case. I know for a fact it happened with UIButton, but I didnt even come to test other types I had registered..

Edited by Grimshaw

Share this post

Link to post
Share on other sites

Which version of AngelScript did you use before on Android? Maybe I can spot the problem by comparing the code of the two versions.

Share this post

Link to post
Share on other sites

It was 2.23.0 .


It worked then, and the bug was introduced when i swapped to the latest one. (The upgrade was really smooth, no changes needed anywhere, just added PushState and PopState to all calls)


EDIT: Im sorry, I tried my best for the debugging part and I could not get anywhere.. I learned how to know which line and function crashed the program and that works fine for other crashes and is actually helpful. However, for the crash dump from the unfixed latest version, it is not able to locate any useful info and with the patched version you gave me today no crash dump is even generated, just a immediate death of the program.


I really have no idea how to be helpful debugging this, my best bet on whats crashing is the assembly code for ARM (because it cant probably locate debug info for that) but I have no idea.. 


Noone got this working before me? Strange..

Edited by Grimshaw

Share this post

Link to post
Share on other sites
Tomorrow I'll compare the current code with version 2.23.0. It's almost exactly a year between them, but I don't believe the code for native calling conventions on Android has changed that much. Hopefully I'll be able to identify the problem.

Share this post

Link to post
Share on other sites

Allright, just notice that in 2.23.0 I did not use native conventions on android! Its the first time now and I never saw it work at all, so nothing to compare to! If you meant for the other bug, then its allright :D

Share this post

Link to post
Share on other sites

Oh, ok. Then it is going to be difficult.


I'll see if I can find the time to install the Android development kit and play around witth this, hopefully there shouldn't be a lot of changes needed, but a lot of tests needs to be made to determine what's wrong. Especially since debugging seems to be so difficult. This will take time, so you'll need to continue with the generic calling conventions for now.


The problem is reproducible in the emulator in the Android development kit as well, right? 

Share this post

Link to post
Share on other sites

I don't know that as I always use real devices for testing, but the emulator is a true ARM emulator so it is supposed to be "EXACTLY" like a real device..


I will stick to the generics, yes. I would like to give you further help and I will if you need, but I am not sure what to do anymore as I dont have any fair logic of assembly and native conventions..


I've been trying to debug the crashes with ndk-stack but nothing is reported to me.. its weird..hard to debug..

Share this post

Link to post
Share on other sites

Can you do a disassembly of that void testP() function you tested with? Or rather, compile the function to assembler code (compiler switch -s, I believe).


At least I should be able to see if the assembler code is how AngelScript expects it to be.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement