19 replies to this topic

[_Engine_]

Hi!


We are using angel script in our game engine, but we encountered with serious problems. Before 2.25 we try use precompiled byte-code but
they are was error in loading byte-code. So we just compile script in runtime and this works fine until script became too big and app on ios forced to close because too much memory consuption take place when compiling script. Now with 2.25 when we save byte code angel script just crashes.

Also always triggered assert in when compiling script
as_compiler, line 925
if( !hasCompileErrors )
{
asASSERT( tempVariables.GetLength() == 0 );
asASSERT( reservedVariables.GetLength() == 0 );
}

Can we send source code and nessesery data so you can debug angel script code and figure out what we did wrong or what bug lie in angel code?


Best regards.

[Andreas Jonsson]

Asserts in AngelScript is most likely a bug in the script engine. Sometimes they may be hit due to invalid scripts, but it would still be a bug in the library.

When the assert happens in the compiler, can you inspect the outFunc member in the compiler to determine which script function is being compiled, and then post that function here (or send it to me by e-mail) so I can take a look at it?

If the assert hits in the compiler, how is it that you manage to save the bytecode?

Please don't send me the full source code. At least not without trying to narrow down the problem first.

[_Engine_]

Hi!

Аssert itself not a problem because script work fine. Real problem is not working precompiled byte code - previosly byte code load don't work and now byte code saving are broke and this is real problem because we working at commercial project and almost failed because angel script leads to huge techincal problems with we can't solve by ourselfs (((

[_Engine_]

just send function is not a solution because we have very complecivity using of angels code so only full code is solution and also we cannot fix angelcode bug because problem too complex (((

Edited by _Engine_, 18 October 2012 - 02:44 AM.

[Andreas Jonsson]

The fact that the assert fails is likely the related to why the precompiled code doesn't work, even if running the scripts work seems to be working ok.

The specific assert that is failing tells me that the compiler is doing something wrong with the temporary variables. There is probably a specific expression in which the compiler fails to deallocate one of the temporary variables. This kind of problem can make the code in the bytecode serialization fail is the instructions don't match up when it adjust the positions to keep the saved code platform independent.

Seeing the function that causes the assert failure will hopefully allow me to identify what expression the compiler is having trouble with in order to fix it.

[_Engine_]

HI!

looks like i managed how to create script thats halting on assert. Please download this archive - http://www34.zippyshare.com/v/78988412/file.html
In archive modifaed project of tutorial project with comes with angel script and problematic script.

[Andreas Jonsson]

Thanks. I'll look into this as soon as possible.

[Andreas Jonsson]

I've reduced the script to the following:

shared class SPoint
{
  SPoint@ opAssign(const SPoint&in assign)
  {
    return this;
  }
}
class SBuilding
{
  void ReleasePeople()
  {
    SPoint cellij;
    if ( GetRoadOrFreeCellInAround(cellij) ) // <-- the assert happens here
    {
    }
  }
  bool GetRoadOrFreeCellInAround(SPoint&out cellij)
  {
    return false;
  }
}

It's definitely a bug in the compiler. I'll let you know when I have it fixed.

[Andreas Jonsson]

Alright. I've fixed the assert() failure in revision 1441.

The assert() was hit because the SPoint opAssign method returned a handle instead of a reference. This caused the compiler to allocate a temporary variable to store that handle, but it was then never released again. This was actually causing a memory leak, as the SPoint object would never be freed.

Let me know if you still have trouble with saving/loading the bytecode after picking up the fix.

If the problem still exists, then can you call the WriteConfigToFile() function from the helper add-on in your application after registering the interface? It will save all the registered functions to a file that I can then use to recreate the same configuration even without the full implementation of your engine.

Regards,
Andreas

[_Engine_]

Thank's. I wiil try tommorov new revision.

[_Engine_]

Hi!

So there are no more halting on assert. But precompiled bytecode still do not work properly. Looks like problem lies in imported functions. Somehow some function do not imported successfully from another module. This functions use shared classes as input and return value. In simple script i cannot reproduce problem. We have no choise expect drop off imported functions and use function pointers instead.

[_Engine_]

Hm, looks like function pointers is something strange. Imported functions are planned to deprecate in Angel Script 3.0 but i can't understend how modules can communicate using function pointers. So imported feature do not work and there are no another solution. We are stucked (((

[_Engine_]

Hi!

So problem is - byte code can't load and it return -1 on loading. Error comes when loading shared constructors section.
This link http://www63.zippyshare.com/v/43593543/file.html leads to archive with modifaied sample "include" from angel code also archive contain scripts with leads to bug when loading shared classes.

[Andreas Jonsson]

Thanks. I'll investigate the problem and have it fixed as soon as possible.

[Andreas Jonsson]

I've reduced the problem to this script:

shared enum ResourceType {}
shared class Resource
{
  void getType(ResourceType) {}
}

There is definitely something wrong with the combination of the shared enum and shared class.

I'll update when I have the fix.

[Andreas Jonsson]

I've fixed the bug in revision 1444.

The problem was that the shared enums were not treated as shared when loading the bytecode, so each module got its own unique enum. This caused the other shared entities (classes, functions, etc) that used that enum to not match the original declaration, which is why the loading failed.

Thanks for the help in producing the code that allowed me to debug this.

[_Engine_]

Big big thanks

this problem was gone but, but i found another bug.
This link to archive with problem code - http://www36.zippyshare.com/v/57990345/file.html
in sample fisrt loaded testbed.as and second goes second.as. BuildingDesc are included in testbed.as but not in second.as but comiler successfully find SBuldDesc when compiling second.as. When we try load bytecode for second.as complier can't find SBuldDesc and that is right. So problem is compiler find description of type that declared in another module but this must be are error as it is when loading bytecode or this should work and for byte code but i think is wrong becasu this no logical.

[Andreas Jonsson]

You're right. The compilation of second.as should fail if it doesn't declare the shared SBuildingDesc. I'll look into this when I get home tonight.

[Andreas Jonsson]

The problem was with shared classes. When a shared class was found during compilation and it had already been compiled in a previous the members were not compiled again so it wasn't detected that they were using some types that were otherwise not declared in the script. When the script was then saved, the full declaration of the shared class was saved including the reference to the other types.

I've fixed this in revision 1445. The missing declaration will now be properly detected during compilation of the script.

[_Engine_]

Thanks

Looks like now all work fine