I7: P49 error on Mac (I have Windows)

Rob Menke’s transcript for my IFComp 2013 entry, Threediopolis, at the-wabe.com has

*** Run-time problem P49: Memory allocation proved impossible.

*** Memory ran out ***
*** Memory ran out ***
*** Deep copy failed: destination empty ***

I haven’t been able to contact him, and I’m unable to reproduce this with stress tests. I have a feeling it has something to do with indexed text based on

https://intfiction.org/t/indexed-text-and-tables/3083/2

(which points to a coding error by not accessing tables etc.)

And also

rec.arts.int-fiction.narkive.com … -7-project

Are all I’ve found. The second link indicates a possible interpreter shortcoming.

I’ve tried stress testing, which consists of randomly walking around my game, examining things and trying bad commands. I’ve also tried checking every line of code that refers to a table entry or indexed text. I’ve found nothing untoward, but that may not mean anything.

Unfortunately a code snippet is not possible, either, since the game’s 100kb of source.

Does anyone have any ideas how I can check further for this bug? Maybe I am overrunning a buffer Windows terps find OK but Macs don’t?

Thanks!

This memory allocation error comes from the Z-code file, which is the same between Mac and Windows. There’s no buffer being used outside the Z-machine’s memory.

The first sign of trouble is the “memory ran out” error. That implies that (indexed-text) memory really did run out; it doesn’t look like the interpreter-shortcoming case.

I’m not sure what else to say. It’s possible that something in I7’s generated code is leaking memory; or you might be doing something that leaks memory; or there might be fragmentation in the indexed-text memory buffer. Or the player might have done something that genuinely needed more memory than was available.

Can you reproduce this by doing everything in the transcript? Or is the game too random for that?

I experienced the bug when playing your game too. I can’t remember what triggered it.

Thanks, Zarf. The game isn’t random, but there’s so much to try that it may be tricky to do everything possible. About all it seems I can do is try to access every entry in the tables I wrote and see what blows up.

Still, I’ll try to write a test case–or group of cases–that goes/go through (almost) all code paths, or barring that, all table entries.

And thanks, Dannii. Would you remember/be able to check the version of the game you played? Also, were you running the item list in the status line? No problem if you don’t remember. My strong guess is an intra-comp update may’ve broken things. That narrows code paths down, of course.

Unfortunately, web logs on ifcomp.org don’t show any such errors, so I can’t track that.

Ohh, yes it was only a problem when the list was in the status line.

Thanks again, Dannii. This is a big help. I’ve found nothing yet, but I’m still running tests on different interpreters.

To follow up on my own post:

I noticed section 19.2 in the Inform manual. I mean, I’d read it before, but I just forgot about it. It seems like I really should define these and possibly change the file type to Glulx to provide further robustness. I did not. I for some reason wanted to keep the game as a zcode.

Use dynamic memory allocation of at least 16384. [I’m not sure if this does anything but it can’t hurt.]

Use maximum indexed text length of at least 3000.

Dannii’s observation that the game only blows up with the header was a useful one since a maximum indexed text length of 1000 creates problems. At 22 characters per task (47 of them) I would overrun a buffer even if the text length were expanded. This stepping on memory would not always show up, but with a stricter compiler, it would.

And also, just doing arithmetic here, I think that 3000 should be adequate–that makes 63 characters per task (there are 47). I’m not sure if (italic text on/off) counts in that, but it seems like it won’t add enough to cause a problem.

This looks like a decent bandage, but I don’t know if it’s good enough. Does this seem technically sane? It seems like the program gobbles up a bit more memory this way, but it shouldn’t be a huge deal.