Fatal Memory Access Error with Dynamic Objects

Authoring Inform 7
1

We use Dynamic Objects in Kerkerkruip to clone scrolls that you can find somewhere. It has recently stopped working, producing “Fatal Error: Out-of-bounds memory access”. As far as I can tell we haven’t changed any relevant code. (I did a git bisect which didn’t help - it said the error has existed for months, but we’ve never seen it until a day ago.)

When I comment out the cloning code it works fine.

I’ve tried increasing dynamic memory allocation, which doesn’t help.

The relevant code is at github.com/i7/kerkerkruip/blob/ … .i7x#L1166

Any ideas?

2

I can try to troubleshoot. What do I need to do to reproduce the error?

3

These commands will do it. In the current code state it appears to be 100% reliable. (In the older code when I was bisecting it was less reliable.)

gonear quartering search pile

I can give you a built file, or you can download the source code: github.com/i7/kerkerkruip/archive/master.zip
But unfortunately Kerkerkruip is a mess to set up. In addition to the extensions in the source code the extensions in this file need to be installed: github.com/i7/kerkerkruip/blob/ … extensions

If the line I linked to above is changed to the following it no longer has an error:

let the new scroll be [a new object cloned from] the template;

It doesn’t do what we want it to do of course.

I didn’t think to check whether commenting out the next two lines, but leaving the cloning code in, helps. I’ll do that now… [edit] Doesn’t help.

thanks for giving it a try!

4

All right, give these a try. If all goes well I’ll submit them this weekend.

This version of Dynamic Objects fixes the bug you found, which turned out to be an invalid memory access resulting from trying to clone certain built-in relations.

This version of Dynamic Tables fixes an unrelated bug, but I apparently forgot to release it back in 2010, so this is as good a time as any.
dynobj-v7-dyntab-v4.zip (15.2 KB)

5

Thanks! Your explanation seems strange because I didn’t think scrolls were involved in any relations, but then, sometimes the nature of I7 means that seemingly unconnected pieces of code can have unexpected consequences on each other.

6

Specifically, the one causing problems was the containment relation. It’s returned by IterateRelations like any other various-to-various relation between objects, but doesn’t use the same storage format (and logically shouldn’t be cloned anyway).

7

These updated extensions seem to have fixed everything. Thanks!