Alright, I'm not sure I got all the details correct here, but here goes.. asCExprValue::stackOffset is a type short (which is signed):

https://github.com/codecat/angelscript-mirror/blob/6888f245e61d7cd2728e7f3f0e088dcec4e22066/sdk/angelscript/source/as_compiler.h#L105​

Which is used here:

https://github.com/codecat/angelscript-mirror/blob/6888f245e61d7cd2728e7f3f0e088dcec4e22066/sdk/angelscript/source/as_compiler.cpp#L3502​

In my case, stackOffset is 0x9c4e, which as a signed value would be -25522, but the length of globalProperties is 40015. Should stackOffset be turned into an unsigned short to fix this problem? (eg. 0x9c4e = 40014)

Additionally, it seems kinda weird that globalProperties has 40k items. My reproduction case is that I have many different modules with many scripts - I don't really want to make a new asIScriptEngine for every module either (there's a LOT of bindings in my script engine). I never thought I'd reach any kind of hard Angelscript limitations like this! Any thoughts/advice on that would be welcome.

I just tried changing it to an unsigned short which does fix the problem in my reproduction case for now. In the long term however this won't be a great solution I think.

(Relevant bug report: https://github.com/openplanet-nl/issues/issues/60)

Ouch. Your scripts are growing very big. I never thought I would see such big scripts. ?

Rather than making stackOffset unsigned it would probably be more appropriate to make it 32bit long. I think that might have less risk of causing any negative impact (negative stack offsets are used to reference function parameters on the stack).

I'll have to generate a test with lots of global variables to stress test the compiler's limits and come up with a formal fix.

Thanks, I'll revert my unsigned short change then, I suppose that's probably not the best thing to do :D

I actually just realized where the 40k globals come from - there are ~40 script modules and they are all each including 1 script with ~900 constant global strings. I can easily optimize this and (permanently) fix it, but should all these globals exist in the same script engine? Shouldn't they exist only in a script module?

I've fixed this in revision 2764

Miss said:
I actually just realized where the 40k globals come from - there are ~40 script modules and they are all each including 1 script with ~900 constant global strings. I can easily optimize this and (permanently) fix it, but should all these globals exist in the same script engine? Shouldn't they exist only in a script module?

Yes, each script module will get its own instance of the global variable. When I manage to implement support for shared global variables then this could easily be resolved, but for now try to include only the global strings actually used in each module.

Thanks for the fix! Running into this problem was enlightening. ?