Ok, I’m at my wit’s end. I’m working on a rather complex Glulx game, using the latest 6.32 compiler, and after replaying some commands, the interpreter (either GIT or Glulxe) pegs the CPU at 100%. No errors are generated by either the compiler, the game, and nothing is written to any log files. After a certain point in the game, no matter the command, the interpreter bugs out and goes to 100%. I’m thinking that it’s an endless loop of some sort, but the lack of debug information makes it difficult to track down. I’ve noticed that not a single react_before or before is hit; the process goes to 100% before that happens, which makes me wonder if the problem is not the game itself, but something further down (interpreter or language).
Anyhow, does anyone have any ideas on how to go about troubleshooting this? None of the interpreters allow you to file bugs (or no-one ever has); there’s no mailing lists (except for Gargoyle, but it’s not a Gargoyle issue, as Zoom has the problem too).
I’m making blind guesses … but here are a few questions that might help narrow it down:
Are you using any sounds or graphics in your game? Or is it a standard text-only game?
You say it happens during replay. Does that mean it doesn’t happen if the same series of commands is entered manually?
Does it always or only happen in the same place in the replay, or does it happen quasi-randomly at different places?
How close are you to maxing out various values, such as MAX_STATIC_DATA (or whatever it’s called)? Have you tried increasing any of them to see if the problem goes away?
What happens when the CPU goes to 100%? Does the computer freeze, or just the terp app?
Have you tried running with a high trace level to see what steps the game is proceeding through?
In a large game, stripping down the code is an enormous task, of course, but ultimately that may be the only way to solve the problem. I would start by looking at anything non-standard or non-vanilla in the code.
It happens in the same place in the replay, and it’s not a function of replay – manually entering the commands does it, too. Not sure about the various constant values, but that’s a good idea. I’ll try that.
Yes, we have one graphic and one sound file so far. They are both at the beginning of the game, so I’m pretty sure that they aren’t causing a headache.
When the CPU → 100%, just the interpreter process hangs (Git or Glulxe). The machine is ok.
Yup, I’ve tried trace and actions on. As soon as I enter a command (after I’ve gotten to the location where this all happens), bang, zoom, 100% CPU.
I’ve had to strip it down before, but I really didn’t want to because it’s quite large. Sigh. Anyhow, thanks for the reminder on the constants. I’ll check those out.
One thing I would check is: you doing anything at all with scope? The parser is pretty easy to send into an infinite loop when toying with scope. This includes things like the When clause in “understand…as…when…”
Does it happen for the first command in that room? If not, then what did the previous command in the room do?
IIRC, compiling with -g should make the game output each call to a function as it occurs; this may help you narrow down where in your code the infinite loop is occurring, though it is likely to be very verbose.
Yeah, I’m playing with scope quite a bit. I’ll check that out too. I’m sure I can reduce some of my scope monkeying. (And it does seem to be an endless loop situation.)
I’ve tried the -g. Not sure why it’s not working, as I’ve seen the output before, but perhaps something in Glulxe is forbidding it.
I don’t think it’s the static variables, at this point. I’m not near any maximums.
You could get into the same infinite loop in I6, but only if you wrote the same style of parse_name routine that the I7 compiler uses. That’s unlikely, because it’s a rather convoluted style.
(To be safe, don’t do any scope tests inside a parse_name routine.)