Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 24 Aug 2010
Offline Last Active Dec 11 2013 01:23 PM

Topics I've Started

Debug information invalidates the bytecode

02 April 2013 - 08:11 PM

Edit: false alarm, see below


Tested on rev1602. Empty lines (or otherwise syntactically insignificant lines, such as comments) can make the saved bytecode unloadable due to some problems with source line debug information. The following fails to load from bytecode unless debug information has been stripped:


funcdef void FUNC();
class T
    FUNC@ f;

void tmain()
    T t;
    @t.f = test;

void test()

LoadByteCode() returns asERROR. Removing any of the empty lines before the actual code begins seems to solve the issue.

Compilation crash, possibly on error output

23 February 2013 - 03:27 AM

Tested on rev1558. Likely related to http://www.gamedev.net/topic/639247-import-function-with-default-argument/ (indeed the code is a chopped down version of the one found there). The following two modules crash on compilation:


// mod1
import void g(bool dummy, int x = -1) from "mod2";
void f(bool dummy, int x)

void run()
    f(true, 0);
    f(true, 0);
// mod2
import void run() from "mod1";

void g(bool dummy, int x = -1)

class T

T Dummy;


This should give an error saying that an unbound function has been called, but instead it crashes (null pointer access) with the following callstack:


asCTypeInfo::operator= + 110
asCArray<asSDeferredParam>::PushLast + 78, as_array.h (180)
asCCompiler::AfterFunctionCall + 403, as_compiler.cpp (7711)
asCCompiler::PerformFunctionCall + 1450, as_compiler.cpp (11745)
asCCompiler::MakeFunctionCall + 563, as_compiler.cpp (10071)
asCCompiler::CompileFunctionCall + 1957, as_compiler.cpp (8203)
asCCompiler::CompileExpressionValue + 1919, as_compiler.cpp (7256)
asCCompiler::CompileExpressionTerm + 169, as_compiler.cpp (6655)
asCCompiler::CompilePostFixExpression + 296, as_compiler.cpp (6603)
asCCompiler::CompileExpression + 277, as_compiler.cpp (6579)
asCCompiler::CompileCondition + 2440, as_compiler.cpp (6534)
asCCompiler::CompileAssignment + 420, as_compiler.cpp (6344)
asCCompiler::CompileExpressionStatement + 152, as_compiler.cpp (3304)
asCCompiler::CompileStatement + 145, as_compiler.cpp (2520)
asCCompiler::CompileStatementBlock + 260, as_compiler.cpp (1016)
asCCompiler::CompileFunction + 319, as_compiler.cpp (546)
asCBuilder::CompileFunctions + 434, as_builder.cpp (709)
asCBuilder::Build + 41, as_builder.cpp (241)
asCModule::Build + 110, as_module.cpp (223)


Removing any code makes the crash go away, leaving the expected error message, but I am unsure whether default arguments are necessary in the sample to see the crash.

Wrong function called on bytecode restoration

09 February 2013 - 01:12 PM

Tested on rev1549. The bug is sporadic and difficult to pinpoint, its root cause is likely in the bytecode generation rather than bytecode restoration. In a script with a registerd value-type variable placed in the global scope, sometimes another function is called instead of the variable's type constructor when the script is loaded from the bytecode.


Loading the script from the source is without problems. When loading from the generated bytecode, it either works correctly all of the time (for that generated bytecode), or it consistently calls the same, wrong function (which has no special relation to the correct one). Whether the bytecode is buggy or not seems to depend on things like order of compilation of scripts or whether some script was compiled prior to the one in question.


Calling the wrong function naturally leads to bad behaviour, here is the call stack I get when I stumble upon a resulting crash:

    CallCDeclFunctionObjFirst + 38, as_callfunc_x86.cpp (494)
    CallSystemFunctionNative + 885, as_callfunc_x86.cpp (207)
    CallSystemFunction + 294, as_callfunc.cpp (486)
    asCContext::ExecuteNext + 2756, as_context.cpp (2450)
    asCContext::Execute + 521, as_context.cpp (1158)
    asCModule::CallInit + 337, as_module.cpp (310)
    asCModule::ResetGlobalVars + 31, as_module.cpp (254)
    asCReader::Read + 278, as_restore.cpp (98)
    asCModule::LoadByteCode + 111, as_module.cpp (1189)


Maybe it is important that there could be some functions etc. that are registered to the engine after some scripts are already compiled (or loaded from the bytecode). This never caused any problems before though. For the record, the value-type in question is registered this way:

    if(ASEngine->RegisterObjectType("FuncBind", sizeof(ScriptFuncBind), asOBJ_VALUE) < 0)
        Log("%s FuncBind\n", fail);
    if(ASEngine->RegisterObjectBehaviour("FuncBind", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(ScriptFuncBind_Construct), asCALL_CDECL_OBJFIRST) < 0)
        Log("%s FuncBind ctor\n", fail);
    if(ASEngine->RegisterObjectBehaviour("FuncBind", asBEHAVE_DESTRUCT, "void f()", asFUNCTION(ScriptFuncBind_Destruct), asCALL_CDECL_OBJFIRST) < 0)
        Log("%s FuncBind dtor\n", fail);

Bytecode loading error

10 July 2012 - 10:38 AM

Tested on rev1289. The following script fails to load from the saved bytecode:
funcdef void F();

array<F@> arr = { f };

void f()

LoadByteCode method returns -1.

Bug with parsing of callable expressions

03 July 2012 - 08:07 AM

Revision 1289. This code gives a parsing error, "Expected ';'" at the line with arr[0]().
funcdef void F();
array<F@> arr;

void f()

The same issue happens here:
F@ g()
	return null;

void f()

Speaking of funcdefs, Is it possible to allow them to be shared?