NOW I know I'm doing something right:

[oblomov@sociale.network]

NOW I know I'm doing something right:

*** Run-time problem MemoryAllocationFailed: INTERNAL/Extensions/Graham Nelson/Basic Inform.i7xd/Materials/Inter/BasicInformKit/RTPs
*** Memory allocation proved impossible.
*** Stack frame of 0 could not be created ***

#Inform7 #interactiveFiction #OutofMemory

[oblomov@sociale.network]

Apparently this happens when I make the Table of Book Titles too long (more than 6 entries?)

[oblomov@sociale.network]

I am pretty sure my table is not large enough to justify such an error, and upping the dynamic memory allocation limit seems to make no difference.

[oblomov@sociale.network]

I am extremely sure that I should be well outside the limits of the Z machine, but let me try building for Glulx.

[oblomov@sociale.network]

Oh found https://intfiction.org/t/memory-allocation-error-z-code-vs-blank-story-tab-glulx/60213/4 that recommends the $OMIT_UNUSED_ROUTINES=1 flag for the inform6 compiler and that frees up enough space to fix the issue even in z8. Nice.

[oblomov@sociale.network]

OK, if I make the table even larger, the bug reappears. This is definitely an Inform7 compiler bug. I've gone through the code and I can see where the error is coming from: the use of a signed comparison where an unsigned would do makes everything blow up when the base pointer starts from a 16-bit SIGNED overflow. The stack error appears at the start with a ZERO SIZED allocation.

[oblomov@sociale.network]

I can understand why a signed comparison is made, but this needs to be fixed or we can't even make use of the entire available memory on the Z-machine. I'll try submitting a patch that does a DOUBLE check, one for a size overflow (to make sure that the new frame wouldn't change sign) and then the regular “out of stack” check, but unsigned.
I'll throw in an optimization for 0-sized allocations too.