I just tested 2.50, and it gives me an assert at: assert(instr->stackSize == stackSize); Here's a stack trace:

CormoonDebug.exe!_wassert(const wchar_t * expr=0x006dfeec, const wchar_t * filename=0x006dff38, unsigned int lineno=231)  Line 384	C
CormoonDebug.exe!asCByteCode::AddPath(asCArray<cByteInstruction *> & paths={...}, cByteInstruction * instr=0x026c6528, int stackSize=5)  Line 231 + 0x24 bytes	C++
CormoonDebug.exe!asCByteCode::PostProcess()  Line 1452	C++
CormoonDebug.exe!asCByteCode::Finalize()  Line 71	C++
CormoonDebug.exe!asCCompiler::CompileFunction(asCBuilder * builder=0x012ca110, asCScriptCode * script=0x012d5df0, asCScriptNode * func=0x026a0d08, asCScriptFunction * outFunc=0x026b4788)  Line 252	C++
CormoonDebug.exe!asCBuilder::CompileFunctions()  Line 309 + 0x50 bytes	C++
CormoonDebug.exe!asCBuilder::Build()  Line 138	C++
CormoonDebug.exe!asCModule::Build(asIOutputStream * out=0x0012fc00)  Line 110 + 0xb bytes	C++
CormoonDebug.exe!asCScriptEngine::Build(const char * module=0x006d7a6c)  Line 318	C++

So this assert is happening at build, when it's postprocessing the byte code. Since this particular script worked with the 2.41 version of Angelscript, I'm led to believe, that it's either a bug in the postprocessor, or my script isn't compatible with the new version. Well, I'm off to trace what kind of script is actually causing this, and whether I can give you a sample. My script file is pretty big, so I might fail miserably. :D

For example, this function causes the stack size assertion for me. I stripped most of the code while making sure it still caused the assert. Could this just be a programming error on my part, or is it in Angelscript?

void pickOrDrop(ClientData @client, int slot){    Actor@ player;    @player=@client.getActor(0);    if(player==null)        return;//no player actor yet             bool useSecondary;    int itemInSlot=0;    if(itemInSlot>=0){        useSecondary=true;    }    else{        Actor@ p2;        @p2=@client.getActor(0);        if(p2!=null){            return;        }       }}

This would definitely be a bug in the library. Not a programmer error on your part.

I'll look into it.

I just had a look into your code WitchLord, and I can say I have a new appreciation for your work. While it's not overtly complex, I can see how difficult it can be to test for example. Are you using any kind of test framework for it? I can see a few tests included in the SDK, but surely you have plenty more?

It is indeed extremely difficult to cover all possible scenarios. The test framework in test_feature has thousands of test cases that cover most of the possible scenarios, but every once in a while a bug slips through. In these cases I add new tests to the test_feature project so that the bug will never reappear in future releases.

Oh, it does indeed, must have missed over half of them somehow. :)

I found your bug. [smile]

Add the following code to the function asCCompiler::CompileOperatorOnHandles():

	int op = node->tokenType;	if( op == ttEqual || op == ttNotEqual )	{		// If the object handle already is in a variable we must manually pop it from the stack		if( lctx->type.isVariable )			lctx->bc.Pop(1);		if( rctx->type.isVariable )			rctx->bc.Pop(1);		// TODO: Treat the object handles as two integers, i.e. don't do REFCPY		ConvertToVariableNotIn(lctx, rctx);		ConvertToVariable(rctx);

Great, thanks!