Hi Andreas,
I made the entire project from scratch as a static library and it still crashes at the same spot I mentioned in the first post. Perhaps it would be nice to run your testbed on osx. I'm downloading the test_feature source code and see if I can discover anything.

It happens on 64bit Linux too when compiled with AS_MAX_PORTABILITY. It didn't happen on 32bit Linux nor on 64bit Linux without AS_MAX_PORTABILITY.

I'm investigating now what is causing this and why it only happens with AS_MAX_PORTABILITY turned on.

I just ran the testbed on mac os x and here is what I found:

-Everything passes without AS_MAX_PORTABILITY, but not when it is defined (I tested on 32-bit only)
-The AS_IPHONE option keeps being defined even on the project I created from scratch (asGetLibraryOptions returns AS_IPHONE AS_X86!)

When I build my project without AS_MAX_PORTABILITY, it won't crash at the spot I mentioned above, but it crashes when I try to use some of the operators in my vector2 object. The crash this time would happen in the as_callfunc_x86.cpp, which I would guess has something to do with the definition of AS_IPHONE.

Edit: there's a great chance the iphone macro confusion is xcode's fault. I'm still looking into the issue.

The only way AS_IPHONE gets defined is if one of the following defines are found TARGET_OS_IPHONE, _ARM_, or __arm__. Since asGetLibraryOptions() returns AS_IPHONE AS_X86 it seems it is TARGET_OS_IPHONE that is defined, and not the other two.

If I'm not mistaken, this is defined in TargetConditionals.h that comes with Apple's SDK.

Can you check that file, and see how TARGET_OS_IPHONE is defined? Perhaps the define is always made, but with a specific value to identify if iPhone is targetted or not, e.g. #define TARGET_OS_IPHONE=0. If that is the case I need to change as_config.h to check the value of the define rather than just the existance of it.

As for the crash. I found the problem by debugging the tests on Linux 64bit. It was not exclusive to AS_MAX_PORTABILITY, nor to 64bit or 32bit. But it was exclusive to the use of the generic calling convention in the registered asBEHAVE_TEMPLATE_CALLBACK behaviour. If the C++ compiler doesn't keep the function parameters on the stack in the order they are declared then this call would cause memory corruption.

The bug was ancient, but only triggered with an improvement I made back in August (2.25.0) to avoid having the script array add-on be treated by the garbage collector unnecessarily. You happened to be the first one to find the bug as most developers probably do not use AS_MAX_PORTABILITY, thus the behaviour was registered with the native calling convention, or if they did use AS_MAX_PORTABILITY they don't develop on a platform where the compiler doesn't store the function arguments on the stack.

Anyway, the problem is fixed by updating the method asCScriptEngine::CallGlobalFunctionRetBool in as_scriptengine.cpp to the following:


bool asCScriptEngine::CallGlobalFunctionRetBool(void *param1, void *param2, asSSystemFunctionInterface *i, asCScriptFunction *s)
{
if( i->callConv == ICC_CDECL )
{
bool (*f)(void *, void *) = (bool (*)(void *, void *))(i->func);
return f(param1, param2);
}
else if( i->callConv == ICC_STDCALL )
{
bool (STDCALL *f)(void *, void *) = (bool (STDCALL *)(void *, void *))(i->func);
return f(param1, param2);
}
else
{

// We must guarantee the order of the arguments which is why we copy them to this
// array. Otherwise the compiler may put them anywhere it likes, or even keep them
// in the registers which causes problem.
void *params[2] = {param1, param2};
asCGeneric gen(this, s, 0, (asDWORD*)params);
void (*f)(asIScriptGeneric *) = (void (*)(asIScriptGeneric *))(i->func);
f(&gen);
return *(bool*)gen.GetReturnPointer();
}
}


I'll have this fix checked in tonight.

Regards,
Andreas

Can you check that file, and see how TARGET_OS_IPHONE is defined? Perhaps the define is always made, but with a specific value to identify if iPhone is targetted or not, e.g. #define TARGET_OS_IPHONE=0. If that is the case I need to change as_config.h to check the value of the define rather than just the existance of it.

That was exactly it: http://pastebin.com/7nvQCg0G
It'll always define TARGET_OS_IPHONE, but "= 0" on Mac

I'll have this fix checked in tonight.

Great to hear that! I'm glad I could help. Thanks for your time.

I've checked in the fix for the crash now in revision 1503.

I'll update the as_config.h at a later time.

Let me know if you find any further problem.

I've just updated my project with the latest wip and apparently all my internal tests passed. Thanks!