In one of my current projects I’ve got a table with many columns which stores data on different characters. The player can delete rows from this table, and this functionality was working fine just yesterday. However I must have done something as now I’m getting this error:
Glulxe fatal error: Memory access out of range (-67FF7ECC)
The code that triggers this is just:
Carry out going down when the location is character suite:
let N be the current listing;
choose row N in the table of characters;
blank out the whole row;
now the current listing is 0.
I see that there’s been similar fatal errors in the past, but they were said to be a bug in an earlier version of Inform. I’m using 6M62. Any workaround or clue what could be at fault?
I assume you found http://inform7.com/mantis/view.php?id=2114 . This is a situation where the library displays a runtime error and then screws up the error handling after that.
I just double checked by creating an entry for row 1 in the source and changing the code to:
Carry out going down when the location is character suite:
choose row 1 in the table of characters;
blank out the whole row.
There’s definitely a row to blank out: the game can read and display data from entries in the row.
I then tested blanking out a row from a much smaller table with only 4 columns. I got this similar memory error: Glulxe fatal error: Memory access out of range (30130004)
Then I tested blanking a row from that same small table in a new project and there was no memory bug. It is perplexing.
If you add a debugging statement like say "Blanking out row [N]." just before you blank out the row, does it make a difference? Sometimes I’ve run into mysterious behavior when it turned out that a calculation was bugged or I hadn’t set the variable to what I thought I’d set it to.
It was just text and numbers. Away from PC at the moment, but the shortened version of the table that still got the bug was similar to this example:
Table of Characters
Name (text) Age (a number) Hair (a text) Height (a number)
"John" 20 "Brown" 170
With 100 blank rows
The full version of the table has 28 columns which all get written to and read from at various points throughout the code. When I get home later I’ll try narrowing it down by commenting out chunks of code until the bug goes away.
Huh. I couldn’t replicate this in a stripped down test, but when I comment out this line of the code it works fine:
Carry out going down when the location is character suite:
let N be the current listing;
choose row N in the table of characters;
blank out the whole row[;
now the current listing is 0].
Current listing here is just just a number which is changed at various points, initially defined:
Current listing is a number that varies. Current listing is 0.
To appease Inform’s arcane wishes, I have shunted the line out into a new rule:
After going down when the location is character suite:
now the current listing is 0.
And now it works. I mean, technically this issue looks to be resolved, but I have no idea why it happened or what’s to stop it happening again.
There’s nothing about using a variable that way which should cause this problem.
Unless you’re somehow entering this rule when the current listing is zero. But blanking out “row zero” will cause lots of error messages, more than you’re reporting. So it’s probably not that. But it might be worth adding a few lines just in case:
if the current listing is zero or current listing > 100:
say "(BUG) Current listing is [current listing].";
stop the action;
If that doesn’t help, you’ve got a flaky situation where the bug will appear and disappear unpredictably. This is never a heartening situation.
I can only ask that you trim the source down as much as possible while still displaying the problem, and then post it.
I already had a rule preventing the problematic rule from triggering if Current Listing was 0. And indeed, putting in a test line, like
say "[current listing]";
shows that the number is correctly set at the time at which the row is blanked. So far I’ve tried commenting out lots of stuff, but I haven’t seen where the problem is coming in yet.