Actually not. The id in this case isn't consumed.

But I have a couple of leads, I was able to identify some test cases that left a couple of empty slots in the scriptFunctions array. Tomorrow I'll investigate those to fix the problem.

[edit] My english seems to be getting worse :(

If this is of any help,

int asCScriptEngine::GetNextScriptFunctionId()
{
    if( freeScriptFunctionIds.GetLength() )
        return freeScriptFunctionIds[freeScriptFunctionIds.GetLength()-1]; // this never happens...

    int id = (int)scriptFunctions.GetLength();
    scriptFunctions.PushLast(0);
    return id; // ... and so this returns 1, 2, 3 and so forth without ever repeating a value
}

Yes. I identified that bug today, as well as a couple of bugs where a function id was reused incorrectly. I'll have this fix checked in once I get home in a few hours.

I've checked in the new fixes in revision 1556.

Please let me know if this corrects your problem, or if you're still seeing gaps in the scriptFunctions array and/or having the wrong function being called after loading bytecodes.

The fixes do solve the problem of gaps. I will also check if it fixes the problem in the original post.

Have you been able to confirm if the problem was fixed yet?

For now I'll assume this problem has been corrected and won't investigate further into this. Let me know if my assumption is incorrect and I'll take up the investigation again.

I am now getting a crash in my first scenario and it happens somewhere inside this loop:

        if( engine->ep.initGlobalVarsAfterBuild )
            r = module->ResetGlobalVars(0);

The problem occurs with only one module (after many others have been loaded), and it is the only module where I have a registered value-type variable declared in (the module's) global scope. Everything here is loaded from previously saved bytecode. I'll see if I can provide more details, perhaps it's me at fault here.

Even if you find it was something you did incorrectly, please let me know what it was. Perhaps there is something I can do to prevent the crash and instead return a meaningful error code and/or message.

If I put the offending script at the top of the modules to be loaded, it works every time, both from source and from bytecode. But when I move it to the middle of the scripts and load everything from the (already existing) bytecode again, I get a crash and likely a stack corruption (the callstack is garbage). That would indicate there's still some problem with the restoration routine.

I agree. Something is definitely still wrong.

How are the global variables in the module that crashes initialized? Is it just with default constructors, i.e. no explicit initialization, or do you have any initialization expressions?

Does the problem also happen if you comment out most of the global variables? Are you able to narrow it down to a single global variable?