Jump to content

View more

Image of the Day

Adding some finishing touches...
Follow us for more
#screenshotsaturday #indiedev... by #MakeGoodGames https://t.co/Otbwywbm3a
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.


Sign up now
- - - - -

AngelScript iOS x64

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
27 replies to this topic

#1 Creobit Builder   Members   

103
Like
0Likes
Like

Posted 09 February 2015 - 06:04 AM

Hi, everyone!

We use AngelScript in our engine and it works fine. But since the new iOS x64 requirements were published we have to add x64 support into it.

I get this error every time I try to build AngelScript for iOS armv7 arm64.

Снимок экрана 2015-02-09 в 14.08.05.png

Снимок экрана 2015-02-09 в 13.25.37.png

If I define AS_MAX_PORTABILITY the project builds successfully, but when I call for RegisterGlobalFunction it returns -7 (asNOT_SUPPORTED).

Снимок экрана 2015-02-09 в 14.02.14.png

Снимок экрана 2015-02-09 в 14.03.17.png

Please help me to fix it.

Thanx in advance!



#2 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 09 February 2015 - 01:07 PM

Hi Creobit,

 

unfortunately native calling conventions on iOS 64bit is not yet supported (nor is any other 64bit ARM platform). I don't have access to any 64bit ARM platform so I can't implement this support myself, but if you want to give it a try on your own I can guide you through it. It usually doesn't take more than a week or two to get it to work. Although it involves assembler code it doesn't require a lot of understanding of assembler code since most of the time it is just a matter of copying existing code obtained by disassembling C++ compiled functions :).

 

Compiling the library with AS_MAX_PORTABILITY works but then you cannot use the native calling conventions asCALL_CDECL, asCALL_THISCALL etc. That's why you get the error asNOT_SUPPORTED when trying to register the function 'void sleep(uint)' with calling convention asCALL_CDECL. Instead you need to provide proxy functions that use the asCALL_GENERIC calling convention. The templated wrapper functions in the add-ons will reduce the amount of work needed to write the proxy functions. Most of the time it is just a matter of replacing the asFUNCTION/asMETHOD macro with the corresponding WRAP_FN/WRAP_MFN macros.

 

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

#3 _Engine_   Members   

309
Like
0Likes
Like

Posted 10 February 2015 - 10:17 AM

Hi!

 

Angelscript on iOS x64 have strange trouble - angelscript crashes when null pointer exception occurs in script. Maybe i need use some define that will help to not crash when null pointer exception occurs?



#4 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 10 February 2015 - 02:08 PM

I need more information in order to give an appropriate answer.

 

  • Can you give more detail about the crash?
  • Where is the null pointer exception being thrown from?
  • What does the callstack look like when the crash occurs?
  • Is the null pointer exception you refer o a C++ exception or script exception?

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

#5 Nypyren   Members   

11970
Like
0Likes
Like

Posted 10 February 2015 - 06:25 PM

Be careful when using "x64" - people usually interpret that as Intel x86-64 and not arm64. Say arm64 if you mean arm64.

I'm not aware of iOS running on x64 processors, just arm64 processors.

#6 _Engine_   Members   

309
Like
0Likes
Like

Posted 11 February 2015 - 03:05 AM

Script code thats leads to crash looks like:

 

class SomeClass

{

   float some_value;

};

 

SomeClass@ obj;

obj.some_value = 0;

 

In this sample we just accessing to property of null object.

 

On non arm64 system angelscript just throw null pointer exception. On iOS arm64 system angelscript randomly crashes. Therefore callstack always different.



#7 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 11 February 2015 - 01:12 PM

That's odd. The context->Execute() call should return -3 (asEXECUTION_EXCEPTION) in this scenario. It should definitely not cause any C++ null pointer exception.


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

#8 _Engine_   Members   

309
Like
0Likes
Like

Posted 12 February 2015 - 10:49 AM

Hi!

 

I found that's AS on iOS arm64 system not properly work with inner stack  (somewhere pointers assumed as 4 byte lenght not 8 byte length) when from script called c++ cast function (we register two c++ classes and register cast function from one to another). AmgelsScript crashes after such calls. Maybe somewhere else wrong work with pointers has place.


Edited by _Engine_, 12 February 2015 - 10:52 AM.


#9 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 13 February 2015 - 06:54 AM

This is a different scenario than in your previous one. Does the crash happen in both cases?

 

Can you show me the value of the string returned by asGetLibraryOptions() when called on iOS arm64?


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

#10 _Engine_   Members   

309
Like
0Likes
Like

Posted 13 February 2015 - 07:34 AM

On iOS arm64 asGetLibraryOptions() return follow string - "AS_MAX_PORTABILITY AS_64BIT_PTR AS_IPHONE"



#11 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 13 February 2015 - 01:46 PM

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.


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

#12 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 15 February 2015 - 08:48 AM

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.


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

#13 _Engine_   Members   

309
Like
0Likes
Like

Posted 16 February 2015 - 08:08 AM

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



#14 _Engine_   Members   

309
Like
0Likes
Like

Posted 16 February 2015 - 08:24 AM

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.


Edited by _Engine_, 16 February 2015 - 08:28 AM.


#15 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 16 February 2015 - 10:17 AM

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?


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

#16 _Engine_   Members   

309
Like
1Likes
Like

Posted 17 February 2015 - 09:35 AM

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


Edited by _Engine_, 17 February 2015 - 09:49 AM.


#17 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 17 February 2015 - 05:52 PM

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.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#18 _Engine_   Members   

309
Like
0Likes
Like

Posted 18 February 2015 - 07:19 AM

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.



#19 Andreas Jonsson   Moderators   

4652
Like
0Likes
Like

Posted 18 February 2015 - 07:53 AM

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.


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

#20 _Engine_   Members   

309
Like
0Likes
Like

Posted 18 February 2015 - 08:58 AM

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


Edited by _Engine_, 18 February 2015 - 11:11 AM.





Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.