I7: my story produces a fatal memory error in Glulxe
MW
project in the I7 editor, and I've run into a persistent crash. In
one of the test paths I've set up, my story runs for 268 turns, doing
various things, and then, at a point when an action causes an indexed
text to be manipulated a bit and then printed out, the editor reports:
Glulxe fatal error: Memory access out of range (1B9600)
and the game crashes. This bug is easy to reproduce via that lengthy
test path, but it seems very sensitive to its environment and I don't
know how to reproduce it via a shorter path--or, more importantly,
within a simpler game. (My game is not simple.) The things the game
is supposed to be doing when it crashes are done correctly at other
times, and clearly no I7 code that's legal enough to compile at all
should produce such an obscure error message anyway. So there's a
bug, I guess, in one of my tools--either Glulxe, or the Inform
compiler. I suspect the latter, since I've produced a similar-looking
crash once or twice in Git (but not at the same spot in the same
path)! But I don't know. Can y'all guess at what might be
happening? If I knew more about it, maybe I could reproduce it in a
small program. That would be nice.
This isn't blocking me in the short term; I can remove the crash from
this test path by increasing the maximum indexed text length. But
that gives me little assurance that some other path through my game
won't still cause a crash. Before I release my game, I will have to
fight this bug....
David Kinder
> Hello, I wonder if you folks can advise me. I'm trying to test my I7
> project in the I7 editor, and I've run into a persistent crash. In
> one of the test paths I've set up, my story runs for 268 turns, doing
> various things, and then, at a point when an action causes an indexed
> text to be manipulated a bit and then printed out, the editor reports:
>
> Glulxe fatal error: Memory access out of range (1B9600)
This means that the game has tried to read from (or write to) an impossible
memory location, outside the space of the game. Tricky...
Does the game's source (or any extensions you're using) use the function
print_to_array()? There's a problem in the one argument form of this call
that's shown up recently, and is the cause of Rover's Day Out not working on
some interpreters. This might cause the behaviour you're seeing.
David
MW
> memory location, outside the space of the game. Tricky...
>
> Does the game's source (or any extensions you're using) use the function
> print_to_array()? There's a problem in the one argument form of this call
> that's shown up recently, and is the cause of Rover's Day Out not working on
> some interpreters. This might cause the behaviour you're seeing.
>
> David
Not explicitly, no. (I don't know anything about that function.)
I do play around with indexed strings a lot--I index into them,
replace pieces of them, and so on; it's nothing exotic but I think I'm
doing an unusual amount of it. At one point I had to hardcode a lot
of strings into the game, when the task of generating them (via
perfectly sensible, legal I7 code) bogged down and eventually
destroyed Glulxe and even Git astonishingly quickly. I was angry
about this! It left me with the impression that Glulx interpreters
don't really expect you to do very much with indexed strings. Or
maybe this would also be attributable to the I7 compiler.
Andrew Plotkin
> > This means that the game has tried to read from (or write to) an impossible
> > memory location, outside the space of the game. Tricky...
> >
> > Does the game's source (or any extensions you're using) use the function
> > print_to_array()? There's a problem in the one argument form of this call
> > that's shown up recently, and is the cause of Rover's Day Out not working on
> > some interpreters. This might cause the behaviour you're seeing.
>
print_to_array() is a low-level way to convert I6 string data into
array data. I7 doesn't use it normally -- there are better facilities
in the library -- but I'm not sure about all the extensions out there.
The error you posted doesn't look exactly like the problem that David
is describing, but that doesn't prove it's not.
> I do play around with indexed strings a lot--I index into them,
> replace pieces of them, and so on; it's nothing exotic but I think I'm
> doing an unusual amount of it. At one point I had to hardcode a lot
> of strings into the game, when the task of generating them (via
> perfectly sensible, legal I7 code) bogged down and eventually
> destroyed Glulxe and even Git astonishingly quickly. I was angry
> about this! It left me with the impression that Glulx interpreters
> don't really expect you to do very much with indexed strings. Or
> maybe this would also be attributable to the I7 compiler.
This has come up in a couple of recent threads...
You're right that the I7 system isn't great with heavy use of indexed
text. Where the responsibility falls is still up in the air, I think.
I don't want to say "It's bad form, avoid it;" neither do I want to
say "I7 will be better optimized for indexed text in the future, so go
for it."
In fact, I think both of those statements may be true. :) But they're
opinions, not official declarations.
The objective situation is that indexed text is a very new addition to
I7. I7 was created to compile to Z-code (and later Glulx), via I6.
Glulx was designed to be targetted by the I6 compiler, so it encodes
many of the same design decisions as Z-code. And Z-code had no notion
of allocatable memory. Strings were fixed, frozen objects, created at
compile-time. All text variation was accomplished by writing functions
whose behavior was dependent on object and property state.
We've tried to create a smooth upgrade path from Infocom's programming
model to something more modern. It's not as smooth as one would wish.
You can still see plenty of design decisions fossilized into I7. For
example, the pre-indexed-text format for variable strings:
"Quoted string [object name] [if ...]conditional text[end if]"
...is exactly the old notion of "a function whose behavior is
dependent on object state". This is awkward for anyone whose notion of
string handling comes from the Perl/Python world. (Including me!) But
Z-code and Glulx are highly optimized for it. Dynamic string handling
is implemented at the library level, not the interpreter level, so it
is inevitably slower. Same goes for regexps.
As a game coder (with plenty of Z-code and I6 experience), I say "The
hell with the new stuff -- I'll stick with the old model." Speaking as
a system architect, I say "Yeah, you old assembly-coding dork, you do
that. The rest of us are going to drag this platform into the modern
era, and then polish it up so that it works better that way."
Then I realize that I'm talking to myself, and go wash my face and
pretend nothing happened.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
MW
> array data. I7 doesn't use it normally -- there are better facilities
> in the library -- but I'm not sure about all the extensions out there.
>
> The error you posted doesn't look exactly like the problem that David
> is describing, but that doesn't prove it's not.
Well, the source code for my game and for the extensions it uses
(beyond the ones included with I7) does not include the term
"print_to_array". So I guess I'm not using that?
I've gotten over my prior problem with indexed string handling, but I
don't think I can hack around this present bug without crippling my
game (or devoting a tremendous amount of work to it). So far my best
option appears to be increasing the maximum indexed text length to
stop the crash that's immediately blocking me, and then testing
heavily to make sure that no more crashes will arise within a large
number of somewhat ordinary runs through the game. But if other
crashes do arise, how will I stop them? Is there any horrible hacky
way in which I can tell Glulxe or Git to just ignore its memory
error? Probably not I guess. If this were a general-purpose
programming language, rather than I7, then I could, if nothing else,
make my game back its state up once in a while....
Andrew Plotkin
> > print_to_array() is a low-level way to convert I6 string data into
> > array data. I7 doesn't use it normally -- there are better facilities
> > in the library -- but I'm not sure about all the extensions out there.
> >
> > The error you posted doesn't look exactly like the problem that David
> > is describing, but that doesn't prove it's not.
>
> Well, the source code for my game and for the extensions it uses
> (beyond the ones included with I7) does not include the term
> "print_to_array". So I guess I'm not using that?
That's correct. You'd see it in the extension source code.
So it's something else. I have no ideas as to what. This is, as I
said, new functionality. You might have uncovered a bug in I7's
memory-management code. Or in one of your extensions. You might have
run out of memory, or fragmented it in some pathological way, and then
run into a bug in the warnings that should appear to announce this
fact.
> I've gotten over my prior problem with indexed string handling, but I
> don't think I can hack around this present bug without crippling my
> game (or devoting a tremendous amount of work to it). So far my best
> option appears to be increasing the maximum indexed text length to
> stop the crash that's immediately blocking me, and then testing
> heavily to make sure that no more crashes will arise within a large
> number of somewhat ordinary runs through the game. But if other
> crashes do arise, how will I stop them? Is there any horrible hacky
> way in which I can tell Glulxe or Git to just ignore its memory
> error?
You can compile Glulxe without memory-map bounds checking. Then the
game will instead write into the interpreter's memory heap, eventually
crashing it. This is not something that I recommend you recommend to
your players.
vaporware
I would blame this on the implementation of indexed text having to
stay compatible with Z-code. There's no reason a Glulx program
couldn't do dynamic strings by creating uncompressed Glulx string
objects at runtime; that's exactly what I did for Snack. But on Z-code
you have to choose between arrays (easy to index and create, hard to
print) and strings (easy to print, hard to index and create), so to
avoid duplicating code, we end up stuck with arrays on both platforms.
vw
David Kinder
> Not explicitly, no. (I don't know anything about that function.)
>
> I do play around with indexed strings a lot--I index into them,
> replace pieces of them, and so on; it's nothing exotic but I think I'm
> doing an unusual amount of it.
I guess we're just going to have to debug it the hard way, then :-) If you
email me the Inform 6 source that Inform 7 generates (Look in the Build
directory of the project for a file auto.inf after compiling the game but
before shutting Inform 7 down.) and email it to me, along with a description
of how to get the game to fail, I'll have a look to see if I can figure out
what's going wrong, at least at the interpreter level. Once that's
understood we might have a chance of figuring out why what's happening is
happening.
My email address is in the bug report form that's in the root directory of
the Inform 7 installation, by the way.
David
Eliuk Blau
for some strange reason that causes a crash in Windows Glulxe
interpreter? The curious thing is that the error does not occur in any
other interpreter. The file uses Damusix, the timer Glk, and Inform 7.
Sorry I can not send you the code that generates the error, but
basically when you try to check the activation of "Glk timer" during
the execution of IdentifyGlkObjects() the first time the game starts.
It is very strange because if you remove the sentence verification, or
rather, if you remove the glk_request_timer_events() that runs at the
beginning [in IdentifyGlkObjects(), via "Glulx Entry Points"], the
game does not produce a crash in WinGlulxe.
WinGlulxe is the only interpreter in which this failure occurs.
Thanks for your time! =)
Saludos!
Eliuk.
David Kinder
> for some strange reason that causes a crash in Windows Glulxe
> interpreter? The curious thing is that the error does not occur in any
> other interpreter. The file uses Damusix, the timer Glk, and Inform 7.
>
> Sorry I can not send you the code that generates the error, but
> basically when you try to check the activation of "Glk timer" during
> the execution of IdentifyGlkObjects() the first time the game starts.
If you email me the file I'll take a look. It would help if you could
also
send the generated Inform 6 source (the auto.inf file) too.
David