MEMORY issues - over time

Memory usage of the game, when loaded.
I have watched it with Process Explorer.
When the RAM usage reaches approximately 2 Megabytes - it crashes.

This also is the maximum of an "signed 32 bit integer".
The game is 32 bit, but some programming statement is using a Signed Integer for some purpose when it should be using an unsigned integer.
Even if this and all other similar issues were found the game would max out at near 4 Megabytes of usage.

If you are playing online with others, this would make you out of luck.
If you are playing solo with computer opponents, sometimes you can save a game, say every 5 minutes (with a different name for each game) - and you can load an earlier game. When you succeed, the just-loaded-game will often use much less RAM (and then slowly grow).

This also has some downfalls as the parts of the program that Load and Save the game have issues. Loading a game beyond a certain complexity will fail, usually with error "FAF ran out of local 'stack' space during load"

Did somebody actually reverse engineer the allocator and find the actual bug or are you just taking a random guess here? Did you test this without mods? What did you actually do to make the game allocate that much RAM?

I'm not too sure if that has to do with it being a signed or unsigned integer. Pointers which reference memory aren't even integers. It is a reference to a piece of memory. See also:

• https://en.cppreference.com/w/cpp/language/types

On top of that, 32 bit applications are widely known to have only up to 2 gigs of memory and (at certain situations) up to 3.25 gigs of memory. See also:

• https://superuser.com/questions/1163749/why-do-32-bit-processes-have-a-2-gb-ram-limit
• https://en.wikipedia.org/wiki/2_GB_limit

And from Microsoft itself:

• https://docs.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases

The name x86 is an alternative name for 32 bit systems.

Various answers:

Have I "sourcerized" the code. No.

If you have a C, C++ program and are using an indexed array with a signed integer - this can be the result.

If you are speaking assembly language, and using an offset instruction for an address (eg: pseudo code Store RegA, table[RegB] ) - negative issue never happens as the other register is always considered, in this case, unsigned. However with too large an offset it could cause an address fault "You did not own that memory address"

Testing without mods: Could I, Yes. Would I? Boring. These crashes occur for me after the game clock reaches 30+ minutes usually, last night it was game clock 52 minutes (but I am playing computer opponents, and running slowed down game speed). AIX - AI Uveso + several others. If it runs to tech level 3 and many-many experimentals on the battlefield it is likely not a major cross Mod problem (they usually crash almost instantly)

So the problem only exists when you mod the shit out of the game? Im not saying that you are wrong, could be true, but unless somebody takes a close look at the assembly, which probably nobody will, this wont be fixed. Same case as any other engine topic.

There is indeed a small memory leak in the base game - it may very well be caused by the same unit blueprint issues that often cause mods to have sizable memory leaks. Either way, it's mostly a problem that can be substantially addressed in the LUA codebase, and not the engine.