Relations between values defined in the source text, when they grow past a certain size, are at risk of corrupting other data in memory (such as other relations defined below them) or being corrupted by it.

Minimal Source Text To Reproduce

Home is a room.
Foo relates various numbers to various numbers. The verb to foo (it foos, they foo, it is fooing, it
is fooed) implies the foo relation.
1 foos 2.
2 foos 3.
3 foos 4.
4 foos 5.
5 foos 6.
6 foos 7.
Bar relates various numbers to various numbers.
Test me with "relations".

This appears to be caused by the fix for 0000049. In 6E59, global dynamic relations were used directly from the heap. In 6E72, they're still allocated on the heap, but then copied to statically allocated memory and used from there (presumably so that the static address can be used as a constant). When they outgrow their static allocation, their memory overlaps with other data defined afterward, leading to corruption. Also, the heap memory is never reclaimed.

The scheme here is not quite as odd as it looks. We do indeed need the global relation to be at a fixed, I6-constant position in memory, so that it can be used as a constant elsewhere. It therefore wants to be the first block of a possibly multi-block memory allocation which will hold the relation's data during play. However, I7 doesn't know how to initialise relation data (this is all done at run-time in RelationKind.i6t), so it compiles a blank array large enough to hold the opening block and compiles code which will set this block up correctly. This is done by creating a suitable relation and then copying over the block.

The bug was that I7 thought a relation initially used 32 words of data; it actually uses 128. So the space for the initial block of "foo" wasn't large enough, and was overlaid by the initial block of "bar".

The heap-resident block, now representing 128 words of data never to be used, is indeed never reclaimed. This is in order to avoid destroying any objects it points to - indexed texts, for instance. (We could clearly find a way around this if we wanted to, but it's not very much memory.)