The constructor just initializes a single integer field to zero. Rest is by the book. There is only one global variable of my value-type (the type's name is FuncBind) in that module, by step debugging I see that ExecuteNext() reaches asBC_ALLOC (with a script object), then executes the following line

asDWORD *mem = (asDWORD*)m_engine->CallAlloc(objType);

where objType is what it's supposed to be - FuncBind. However at this point the func variable (which I understand is supposed to be the id of the type's constructor) is the id of some unrelated function. This function is called with CallSystemFunction, and the crash happens soon later on

if( a ) *a = mem;

at which point I see a corrupted stack.

It might be important that in our case the registration of certain global functions happens in between loading of modules (either from source or bytecode). Each module has a list of "dependencies" which are registered to the engine just prior to the compilation of this module, unless they are already loaded. The constructor that fails to be called (and the function called instead of it) are both registered like this.

edit: I can also reproduce this with func being the id of a nonregistered function, i.e. a script function. Naturally, CallSystemFunction fails with them on the spot. I have a question, where in ReadInner() "linking stage" there is the translation of registered object's constructor calls? And where are ids of these actually stored - I see that asBC_ALLOC opcodes are followed by a (correct) type pointer, and then pointer to function id - to where do those pointers point specifically?

I think I've discovered the problem in the code.

For some reason that I can't recall why the asBC_ALLOC instruction doesn't have it's function id translated unless the object type is a script class.

That would explain why it works when you always put the script with the global variable as the first module to be loaded, since then the function id will always be same every execution.

I'll have a fix for this checked in soon.

I've checked in the fix for the ALLOC problem in revision 1558.

That would explain why it works when you always put the script with the global variable as the first module to be loaded, since then the function id will always be same every execution.

Strangely enough, I observed the bug even when the script was in the "middle" of all the loaded modules the whole time, without any moving. A case where ids should also stay the same.

Nevertheless, revision 1558 seems to have fixed the issue. I can no longer reproduce the bug in any scenario.

Thanks for confirming the fix.

Most likely when you observed the bug even when in the "middle" something changed without you realizing it. It could have been a additional script function that was compiled, or template instance that was created, or something like it.