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?

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?

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.

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.

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

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.

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.

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.

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?

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.