🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to AngelCode

Crash on iOS arm64

Eugene Solyanov · 2016-04-14T06:49:27

Hi! Looks like i found bug in angle script that leads to crashes on iOS arm64. I will try to explain details. Problematic script is very simple: void main() { NGUIWidget@ wgt = @scene::inst; wgt.alpha = 0.58f; } Variable scene::inst are type of NGUISymbol0Instance and it is binded class from C++. NGUIWidget are also binded class from c++. For NGUISymbol0Instance we register implicitly cast function to NGUIWidget. Binding of cast function looks like Machine()->RegisterObjectMethod("NGUISymbol0Instance", "NGUIWidget@ opImplCast()", asFUNCTION(NGUIWidgetCastGeneric)); Cast function looks like: void NGUIWidgetCastGeneric(asIScriptGeneric *gen) { //On iOS arm64 pointer to object are corrupted and this leads to crash void* obj = gen->GetObject(); } Bytecode of function main are follow: asBC_SUSPEND asBC_PshGPtr asBC_RefCpyV asBC_PopPtr asBC_ClrVPtr asBC_CmpPtr asBC_JZ asBC_PshVPtr asBC_CALLSYS On asBC_RefCpyV correct pointer to C++ class copied to (void**)asPWORD(l_fp - asBC_SWORDARG0(l_bc)); On pc pointer address copied to 0x070d6900 On iOS 64 pointer address copied to 0x12802a1f0 On asBC_ClrVPtr on to (void**)asPWORD(l_fp - asBC_SWORDARG0(l_bc)); copied 0. On pc address is 0x070d68fc and all goes fine because on pc size of pointer is 4. On iOS 64 address is 0x12802a1ec and this is a moment when all things goes bad. On arm64 size of pointer is 8. So coping 0 to 0x12802a1ec leads to corruption of 0x12802a1f0 On asBC_CALLSYS function NGUIWidgetCastGeneric are called. When we extract object address from asIScriptGeneric we get corrupted pointer. I hope my explanation enough to investigate problem.

AngelCode Affiliates

Started by _Engine_ April 08, 2016 01:43 PM

15 comments, last by _Engine_ 8 years, 2 months ago

_Engine_

327

Author

April 13, 2016 07:42 AM

I use only Win32 build and you suggestion right AS_PTR_SIZE is equal 1 thats why offsets are 3 and 4.

And asGetLibraryOptions return AS_WIN_AS_X86.

So i compiling script on Win32 build and expect that produced script is platform independent. And looks like Win32 not produce proper bytecode for 64 bit system.

And if it is true so this is very bad news for us. Because our IDE produce ipa for iOS and on IOS byte code must compatible for 32 bit and for 64 bit either. We cannot produce byte only for one system it is ridicules because not all IOS devices shipped with 64 bit CPU. On Android we use only 32 bit build for compatibility and 64 bit bytecode is useless on android.

So if we need 64 bit build of IDE for produce 64 bit compatible byte code it will broke complity export system of our IDE.

Looks like only way for us is stay with current pipeline and pray thats on arm64 angel script continue work without crashes.

_Engine_

327

Author

April 13, 2016 08:27 AM

Also i checked this code from angelscript.h:


#ifndef AS_64BIT_PTR
#define asBCTYPE_PTR_ARG    asBCTYPE_DW_ARG
#define asBCTYPE_PTR_DW_ARG asBCTYPE_DW_DW_ARG
#define asBCTYPE_wW_PTR_ARG asBCTYPE_wW_DW_ARG
#define asBCTYPE_rW_PTR_ARG asBCTYPE_rW_DW_ARG
#ifndef AS_PTR_SIZE
#define AS_PTR_SIZE 1
#endif
#else
#define asBCTYPE_PTR_ARG    asBCTYPE_QW_ARG
#define asBCTYPE_PTR_DW_ARG asBCTYPE_QW_DW_ARG
#define asBCTYPE_wW_PTR_ARG asBCTYPE_wW_QW_ARG
#define asBCTYPE_rW_PTR_ARG asBCTYPE_rW_QW_ARG
#ifndef AS_PTR_SIZE
#define AS_PTR_SIZE 2
#endif
#endif

So on Win32 define AS_PTR_SIZE will equal 1 and that why byte code not platform independent. It is very sad.

_Engine_

327

Author

April 13, 2016 08:53 AM

I modiffied declaration and AS_PTR_SIZE is always 2


#ifndef AS_64BIT_PTR
#define asBCTYPE_PTR_ARG    asBCTYPE_DW_ARG
#define asBCTYPE_PTR_DW_ARG asBCTYPE_DW_DW_ARG
#define asBCTYPE_wW_PTR_ARG asBCTYPE_wW_DW_ARG
#define asBCTYPE_rW_PTR_ARG asBCTYPE_rW_DW_ARG
#ifndef AS_PTR_SIZE
#define AS_PTR_SIZE 2
#endif
#else
#define asBCTYPE_PTR_ARG    asBCTYPE_QW_ARG
#define asBCTYPE_PTR_DW_ARG asBCTYPE_QW_DW_ARG
#define asBCTYPE_wW_PTR_ARG asBCTYPE_wW_QW_ARG
#define asBCTYPE_rW_PTR_ARG asBCTYPE_rW_QW_ARG
#ifndef AS_PTR_SIZE
#define AS_PTR_SIZE 2
#endif
#endif

But news are bad. Angelscript become crashes on script execution. Crash occurs in IDE and also in modified sample https://yadi.sk/d/bMkASSkJqvbYd

So bytecode definitely not platform independent.

WitchLord

4,838

April 13, 2016 02:06 PM

Hold on. I thought you were compiling the scripts directly in the iOS application. You never mentioned that you were loading pre-compiled bytecode. :rolleyes:

The saved bytecode is platform independent. You can compile bytecode on a 32bit platform, save it to disk, and then load/execute it on a 64bit platform or vice versa.

This puts a different light on the problem. If you're loading pre-compiled bytecode the bug is probably in as_restore.cpp, rather than in the compiler. The code as_restore.cpp is responsible for converting the compiled bytecode to a platform independent format for serialization and then back to platform specific bytecode when loading.

I'll investigate if the code in as_restore.cpp is working properly for this code.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Engine_

327

Author

April 13, 2016 03:59 PM

Sorry for not clear mention about compiling bytecode on Win32 and executing on arm64.

I hope problem will be solved soon :)

WitchLord

4,838

April 14, 2016 02:37 AM

The problem was indeed in as_restore.cpp. It wasn't adjusting the offset for the ClrVPtr at all when the variable the instruction referred to was a null pointer.

I've fixed this in revision 2313.

Regards,

Andreas

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game