Thanks. That appears to be correct.

Since no assembler code is involved, it ought to be possible to reproduce the crashes you reported on other platforms too, as long as AS_MAX_PORTABILITY is used. I'll investigate it further.

I ran my regression test suite with 64bit and AS_MAX_PORTABILITY. Although there were a few problems that needed to be fixed, I'm not sure if any of those are related to the crash you experience.

Can you give the latest version from the svn a try? revision 2126.

This do not help. Still crash occur on null pointer exception.

Looks like i found problem.

With AS_MAX_PORTABILITY i still can register exception function with such call ctx->SetExceptionCallback(asMETHOD(ScriptModule, Exceptioncallback), this, asCALL_THISCALL);

And angelsscript must return error and do not try to use provided exception callback. But angelscript still try use exception callback and use native calling convershios and this leads to crash.

It should work even with AS_MAX_PORTABILITY. The exception callback has a known signature thus it can be called from C++ even without the need for assembler instructions.

Still, you may be right that there is something wrong with regards to the exception callback. Can you set a break point in 'void asCContext::CallExceptionCallback()' and verify if the call is successfully made or if something is going wrong before or after the call to your callback method?

I will try to describe what happens before crash.

When Null pointer exception occurs SetInternalException(TXT_NULL_POINTER_ACESS) are called. Then m_engine->CallObjectMethod(m_exceptionCallbackObj, this, &m_exceptionCallbackFunc, 0); are called. After that crash occurs on (((asCSimpleDumm*) obj)->*f)(param);

Attached screenshot show some details of crash http://rghost.ru/8BlX5jJwP/image.png

There is definitely something wrong. All pointers are null (except param), even the function pointer and the engine's this pointer are null.

I really don't have any clue on how that happen. The SetInternalException method checks the function pointer for the exception callback before calling CallObjectMethod, so it should be able to reach the call with these values.

The callstack is also wrong. Though that might be xcode somehow garbling the callstack after the crash.

Could it perhaps be a race condition with multithreading? Maybe somehow the values are cleared from a different thread?

I'll need your help to figure out what the problem is, because I haven't been able to reproduce the problem yet.

It is my fault - this screenshot was from release version

This screen from debug version http://tau.rghost.ru/8rrdFmJVR/image.png

obj and f are valid but this call (((asCSimpleDumm*) obj)->*f)(param); leads to crash.

I assume that on arm64 this construction must be different but looks to me nothing wrong with this construction.

Yes, you may be right. It is possible that Xcode/arm64 requires the method pointer to be constructed differently.

Can you check a few things for me?

1. what is sizeof(asSIMPLEMETHOD_t)? (I expect 16 bytes)

2. what is sizeof(asFUNCTION_t)? (I expect 8 bytes)

3. what does the method pointer of your ExceptionCallback look like when you register it with SetExceptionCallback? If possible, show me the hex values of all the bytes of the method pointer, and then show me the values rebuilt in asIScriptEngine::CallObjectMethod.

Yes of course.

1. yep length is 16 bytes

2. yep length is 8 bytes

3. this screen shows values in SetExceptionCallback http://higgs.rghost.ru/7rX5FqtNp/image.png

this screen show values in CallObjectMethod http://rghost.ru/8WyWlhRdN/image.png

pointer to method and pointer to object are valid but call (((asCSimpleDumm*) obj)->*f)(param); do not work properly