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! )

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?

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..

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?

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.

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 -

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.

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.

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..

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..