16 replies to this topic

[Andre Santee]

I'm having a crash after I upgraded from AngelScript 2.22 to the latest version 2.25.2. It happens on line 3240 of as_scriptengine.cpp:

[source lang="cpp"]asCScriptFunction *asCScriptEngine::GenerateTemplateFactoryStub(asCObjectType *templateType, asCObjectType *ot, int factoryId){ ... ... ... ... // Tell the virtual machine not to clean up the object on exception func->dontCleanUpOnException = true; func->JITCompile(); // it crashes right here according to xcode return func;}[/source]

The error message is EXC_BAD_ACCESS

I'm using Xcode on a Cocoa application.

I'm using the standard scriptbuilder add-on (from the latest version as well) and the crash happens during module building. I'm using the latest array add-on too.

One thing I noticed is that it only happens if I define AS_MAX_PORTABILITY, otherwise the crash won't happen (though most of my code still won't work but there's a great chance this is my bad, probably because all my code was made to run on MAX_PORTABILITY environment).

I'm running a very minimalistic script in order to make it clearer to debug the crash, which is:
[source lang="java"]void main(){ LoadScene("empty"); Foo[] foo;}class Foo{ int a;}[/source]
I have reproduced this crash on other situations and I'm pretty sure it is the array declaration that causes this crash (if I comment it out, no crash happens).

However, when I declare variations of this array type, behavior changes:

Foo@[] foo; // doesn't crash
Foo@[]@ foo; // doesn't crash
Foo[]@ foo; // crashes

I hope I could give enough details. Has anyone experienced anything similar?

Edited by andrew1b, 07 December 2012 - 03:45 PM.

[Andreas Jonsson]

I'll look into this. As it only happens when you compile the library with AS_MAX_PORTABILITY there a high probability this is a bug in AngelScript. It's been a while since I ran the tests with AS_MAX_PORTABILITY.

Why are you using AS_MAX_PORTABILITY? Is the native calling convention not working for you?

[Andre Santee]

Hi Andreas,
Thank you for the quick reply.

I began using AS_MAX_PORTABILITY because the native calling was crashing my app when I ran on Android. It was mid 2011 though, I remember reporting it in the forums and someone mentioned (can't remember if it was you) that there should be some incompatibility with the arm code and Android platforms.

So I ported all my code to generic calls and I never tried the native calling again. Since I never had performance issues with that, I felt pretty confortable with it. Also, my code runs on at least four different platforms and I'm still expanding, so I decided to stick with the AS_MAX_PORTABILITY.

[Andre Santee]

Hi Andreas, just a small update,
I've been doing some superficial debugging and it appears that, for some reason, the word TARGET_OS_IPHONE is being defined, even though I'm on OS X/Cocoa. I'll look into this and I'll keep you posted (I'll edit this post if I can, to avoid flooding).

EDIT: I did some workaround to force undef the TARGET_OS_IPHONE word but I'm still having crashes, sometimes with, sometimes without AS_MAX_PORTABILITY. I'll run it on Windows when I get to my PC to see if this is a Mac-only thing (though 2.22.x was working fine).

EDIT2: After the latest workarounds I made, I could reproduce the exact same crash mentioned originally but this time without using AS_MAX_PORTABILITY. One thing I think it's worth mentioning, is that I'm still using only generic calling convention. If I'd switch all standard add-ons to register using native calling, it would crash inside native calling functions.

It appears the library has become unstable, something wrong around as_config, perhaps? I can't tell yet if this is happening only on OS X. I'll keep digging.

Edited by andrew1b, 08 December 2012 - 10:38 AM.

[Tzarls]

Are you using the JIT? If so, did you update the JIT when updating AS?

[Andreas Jonsson]

If TARGET_OS_IPHONE is getting defined somehow, then this might be a problem with the project settings. It would appear that the library is being compiled for iOS even though you don't want that.

Are you using the Xcode project from the AngelScript SDK, or do you create your own project? I cannot vouch for the project files that comes with the SDK. These were provided by another user and I don't know how well they work.

[Andreas Jonsson]

I've updated my regression tests to work with AS_MAX_PORTABILITY again. All tests pass successfully on Windows 32bit.

On Monday I'll test the library on Linux.

[Andre Santee]

Are you using the JIT? If so, did you update the JIT when updating AS?

I guess I did. I'm a bit confused now. I have replaced the entire library source code and build files by the new ones. Is there anything else that was not included in the sdk?

Are you using the Xcode project from the AngelScript SDK, or do you create your own project? I cannot vouch for the project files that comes with the SDK. These were provided by another user and I don't know how well they work.

Yes, I'm using the xcode project included in the SDK. It was fine with the previous xcproject, there could be something wrong with the new one, but I'll do more testing. When I simply updated the source files without touching the previous xcproject, macros worked just fine again (still crashes anyway).

I've updated my regression tests to work with AS_MAX_PORTABILITY again. All tests pass successfully on Windows 32bit.

On Monday I'll test the library on Linux.

I'm glad to hear that. I'll try to run it on windows today and see if it is happening only on my mac. I'll keep you guys posted. Thanks for your time.

Edited by andrew1b, 09 December 2012 - 01:20 PM.

[Andreas Jonsson]

JIT compilation is not built-in to AngelScript. If you're using it you have a second library, for example Blind Mind's JIT compiler. Whenever a change to the VM in AngelScript is done, the external JIT compiler must also be updated.

It sounds like the XCode project files has been broken, probably when I received the changes to compile for iPhone in the beginning of the year.

It would probably be a good idea to create a new project from scratch. Can you try that and send me the new project files to include in the SDK?

[Andre Santee]

Hi. I have just tested the updated AngelScript libraries on my windows build of the same project and all my tests passed just fine, no crashes at all. It really seems that the xcode project is broken (hopefully it's just the project, not anything in the library source code which is less likely to happen).

JIT compilation is not built-in to AngelScript. If you're using it you have a second library, for example Blind Mind's JIT compiler. Whenever a change to the VM in AngelScript is done, the external JIT compiler must also be updated.

I'm not using JIT then

It would probably be a good idea to create a new project from scratch. Can you try that and send me the new project files to include in the SDK?

I'll do that and I'll write back soon.

[Andre Santee]

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.

[Andreas Jonsson]

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.

[Andre Santee]

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.

Edited by andrew1b, 10 December 2012 - 02:19 PM.

[Andreas Jonsson]

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

[Andre Santee]

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.

[Andreas Jonsson]

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.

Edited by Andreas Jonsson, 10 December 2012 - 05:14 PM.

[Andre Santee]

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