Using debug-testing commands causes game to freeze [I7]

Authoring Inform 7
1

I suspect that the path forward involves a lot of commenting out big chunks of code and narrowing down which rule is causing the error, but I was kind of hoping that someone has a more direct suggestion.

What I’ve found, having reached a point in development where I want to verify that what I’ve written lately is actually doing what it’s supposed to even when I’m out of the room, is that a lot of the internal “not for release” commands documented in Writing with Inform 24.2–4 cause the interpreter to lock up completely. This is true both in the Inform 7 IDE, using both Git and Glulxe as interpreters, and in both Gargoyle and Glulxe-with-CheapGLK in a terminal, if I test using a “Release for Debugging” .ulx build. In some cases, when running in the Inform IDE, the 'terp locks up so badly that the Inform IDE itself becomes non-responsive—this happens with both Git and Glulxe at the back end, and most frequently when I try to use the “Stop” button after the interpreter has locked up.

What does work, rather than locking up the interpreter:

  • TEST [a test script] (thank goodness)
  • ACTIONS (and ACTIONS OFF)
  • RULES (and RULES OFF)
  • SCENES (and SCENES OFF)
  • RANDOM
  • RELATIONS
  • RESPONSES (and RESPONSES ALL)
  • VERIFY
  • TREE (but see below)
  • SCOPE
  • SHOWVERB [a verb]
  • SHOWHEAP
  • TRACE (plus TRACE 2 through TRACE 6).

What locks up the interpreter:

  • SHOWME [object] (whether or not there is any in-game object that the parser understands the [object] text to match)
  • PURLOIN [object]
  • ABSTRACT [something] TO [somewhere]
  • GONEAR [object]
  • TREE [object]

Debugging commands that cause different problems:

  • SHOWVERB with no verb name crashes the interpreter immediately. In Glulxe-on-CheapGLK, it gives the “Glulxe fatal error: Memory access out of range,” followed by what I take to be a hex memory address, and then exits with exit value 1. If running in the Inform 7 IDE, the Inform 7 IDE itself segfaults. (I have an strace log of this happening if this is helpful.) SHOWHEAP right before doing this shows that the heap is more than 99% free, so I don’t think it’s an out-of-memory error.

In short, it seems that any of these Old High Magic commands fail in this case whenever they try to identify an in-game object.

I’ve tried tracing through the relevant actions and rules with ACTIONS and RULES, but this hasn’t helped: when I run the debug release in Glulx with CheapGLK, to avoid text buffering between outputs, and it does in fact tell me the name of a rule being processed right before the lock-up … but what I find is that if I comment out that rule, then try again, the 'terp will still lock up on a previous rule. And if I comment out that previous rule, why, the 'terp will still lock up on some other rule.

A search ran across this old thread, and tried commenting out the single instance of scope-changing in the game, but that didn’t solve the problem.

So I am mystified, and am probably just going to start commenting out big chunks of code until I eliminate the problem, then try to narrow it down from there. But I’m kind of hoping that someone else may have run across something similar before, and has a suggestion for where to start aside from that.

2

This one isn’t your fault – I see it happening on a one-room game. (Not consistently, though. It does a wild pointer read which may or may not crash depending on the contents of memory.)

I filed a bug on that.

1 Like
3

As for the other stuff… scope tricks were going to be my first suggestion. I see that that was my first suggestion circa 2012. Okay.

Is it possible that you managed to put an object inside itself, or two objects inside each other?

1 Like
4

I have not tried to do so, and a fairly detailed look through the index after a fresh compilation doesn’t show anything turning up contained by/on top of/part of anything that I didn’t expect.

Is there another, more detailed way to check? I suppose I could write a when play begins rule to run through each object, trace up its containment tree until it gets to a room, and make sure it doesn’t encounter itself? (It feels like there should be an easier way to check, though.)

5

Thank you, Zarf!

6

Another possible candidate for issues is Understand rules, and rules that mess with the definition of all. Possibly also does the player mean, although I’m having a harder time imagining how those can break in this fashion.

A common feature of the verbs that are failing vs. the ones that aren’t are that they put every object in scope regardless of the usual rules, so there’s a lot more room for ambiguity.

If you’re using extensions that mess with ambiguity resolution, perhaps also try disabling those (or rules related to ambiguity resolution) to see if it helps.

Have you tried writing trace 7 and rules before writing one of the other commands that triggers a lockup? (Though this may not help because the output may be buffered before it locks up, and never actually printed.)

1 Like
7

That was it. In fact, I’d written a too-general understand rule that, I’m guessing without too much investigation, managed to call itself recursively. Thank you!

That was in fact super-helpful, though I needed to run it unbuffered in Glulxe, using CheapGLK as a back end, in a terminal to see it. Still, when I did, it showed exactly where the execution froze, and that pointed me right to the paragraph in the source text that contained the rule.

Thank you so much!

8

I don’t quite recall exactly what I wrote, but I remember at one point I experienced a similar lockup when I wrote something that was essentially equivalent (but not identical) to Understand "[something]" as a thing. You can see how that might cause issues. :grin:

1 Like
9

There’s something deeply satisfying about being able to blithely go about the process of writing understand rules without having to muck about with the underlying parser in any other way. It makes it hard to resist wanting to specify so many more things that the player just might say. It’s hard not to get a little giddy about it here and there.