A tester ran into an issue with my current z-code game that caused Lectrote to crash on a Mac. The error given was: RangeError: Offset is outside the bounds of the DataView
This error is meaningless to me.
Thinking there must have been a bug in my code, I used my tester’s transcript to repeat all his commands in Windows Frotz, but it did not crash.
I examined my code and couldn’t find anything wrong and certainly nothing that should cause Lectrote to crash. As best as I could work out from the tester’s transcript and screen grab, it had occurred with TAKE ALL where one particular object was taken, whereas taking that object by itself earlier had not caused it to crash. The only unusual thing about this object was that it had an add_to_scope routine that allowed it to bring a dummy object into scope if the equivalent real object was not in scope. The code for that is as follows:
add_to_scope
[;
if (self has general && ~~TestScope(rope))
PlaceInScope(dummy_rope);
],
I then downloaded Lectrote 1.5.3 for Windows 64-bit (i.e. Lectrote-1.5.3-win32-x64.zip), which is a friggin’ huge download. I unzipped it, double-clicked on Lectrote.exe and was greeted by: <path>\Lectrote 1.5.3 is not a valid Win32 application.
I had Lectrote version 1.4.0 installed, so I tried that. After repeating the same commands, it did not crash.
So, my questions are:
Does the Lectrote-1.5.3-win32-x64.zip file contain the correct executable?
Is this executable meant to work on 64-bit Windows 7?
Is there anything different between the z-code interpreters in Lectrote 1.4.0 for Windows and Lectrote 1.5.3 for Mac that would cause the latter to crash?
Tagging @zarf, as he may be able to shed some light on this. I know he’s not a Windows user, so any enlightenment from Windows users is also welcome.
RangeError: Offset is outside the bounds of the DataView
is related to JavaScript and is something like an exception caused by accessing the data outside the valid range. So in my opinion it’s not related to Z-code interpreter itself.
The Lectrote works on Electron console, and probably Windows 7 doesn’t support the recent version. Thus Lectrote 1.4.0 works fine on your system.
In summary, I think that recent version of Lectrote might have some bug, related to the Electron console it uses. Maybe your tester could check the Lectrote 1.4.0 on Mac?
Thanks. That makes sense. I see that Lectrote uses the ZVM interpreter written by @Dannii. As that’s written in Javascript, that may be the cause of the error in Lectrote.
I couldn’t find anything on system requirements for Lectrote or Electron. You may be right about it being incompatible with Windows 7, but I would expect it to run and tell you it’s not compatible, not just spit out a cryptic Windows error message that tells you the wrong thing.
I understand. What I suggested is that the Lectrote Electron console code might caused this general error message, not the Z-code interpreter itself, regardless it’s written in Javascript as well, like you mentioned.
I’m not sure if recent version of Electron supports Windows 7 or it’s deprecated, but I agree that it should print some message. Electron is a high-level web-based framework, not the native library from what I know.
Lectrote includes the browser console in its menu, which would let you see more precisely where the error is occurring.
The only ZVM change between Lectrote 1.4.0 and 1.5.3 is a small bugfix concerning flags 1 in the header, which I don’t think could be causing this crash. But GlkApi and GlkOte were also updated and could be the issue.
No, the underlying Electron library stopped supporting Windows 7 and 8 in 2023. The last Lectrote version which might run on Windows 7 (though I don’t know if anyone tested it) was 1.4.3.
Because I can’t get Lectrote version 1.5.3 to work, I tried it in version 1.4.0. If you choose Window > Toggle Developer Tools and click the Console tab, would that be the console you mean? Assuming it is, I’ll pass this info on to my tester, as I can’t reproduce the bug.
RangeError: Offset is outside the bounds of the DataView
It looks like this error originates only in the DataView class. Nothing in Lectrote or GlkOte uses that class. The low-level Node/Electron framework does, but we’ll need to look at a stack trace to get any farther.
The Electron framework includes the entire app launching mechanism. Unfortunately, if it can’t run, it can’t run long enough to display a message.
From what I checked, the Z-code interpreter supplied with Lectrote uses DataView class in common/utils.js file MemoryView function:
It takes DataView as a parameter in MemoryView,
And also returns new instance of DataView in this function.
So it should be worth looking at this part of the code. Additionally, as Lectrote 1.4.0 works correctly for Garry, it could be nice to check this version on the Mac as well.
That is indeed a bug from within ZVM. ZVM uses DataViews for the game’s memory. With no other similar bug reports in years I’m inclined to think that this means the game itself is buggy, trying to read or outside of its memory limits (or writing outside of the RAM limits). But why wouldn’t it be occurring with any other interpreters? Randomness perhaps? Does the game use much randomness? Does this error predictably occur on your system @improvmonster or only sometimes?
no, i’d never seen this error before. and had never seen it with this game before in previous releases. it only seems to happen when carrying one particular complex object in a particular direction. it involves a rope tied to another object. but, as i say, it didn’t do this in previous releases.
nothing good ever comes from ropes and liquids in IF games…!
From the console log it turns out that the exception is raised within call function, which - from what I understand - calls a routine.
// Return address
stack.setUint32( frameptr, next << 8 );
So, as this is a Stack data structure, I’m just guessing the stack overflow for instance. It may be caused by a routine that is interpreted.
Note, that I’m not familiar with Javascript (nor with Z-code), but know the general concepts.
The stack trace shows, that some Object evaluation is invoking the call, and that it’s called when the line input of the parser is read. I hope that this info will be helpful to catch the reason.
Going back to the original code: note that TestScope does a scope search, which calls add_to_scope on everything in scope, and your add_to_scope routine does a scope search. So that’s a recursive call.
I don’t figure it’s an infinite recursion, because that would hang on any interpreter. But it might be going N^2 deep or something.
It’s better to avoid nesting scope searches like this. Even when it’s not crashing, it’s going to take N^2 time – this single routine could cause perceptible lag.
A stack overflow is an option. I hadn’t thought of it as I’ve never had a report of it before. ZVM uses a 100kb stack which has been enough for everything before.
Thanks to everyone for looking into this. I think @zarf may have identified the cause of the problem:
That code was in beta 3. Looking back to beta 2, I did not use the add_to_scope routine in that version, so it didn’t crash. I seem to recall adding that to overcome a subtle bug. In doing so, I’ve introduced a new bug that leads to the stack overflow in some interpreters.
I think I can handle this differently. I’ll still need a TestScope and add_to_scope, but I’ll do it in such a way that there are no recursive calls. It’s a pity that there are no warnings about this sort of thing in any of the Inform 6 doco or warnings provided by the compiler.
Disaster averted. I changed the code to get rid of the recursion. @improvmonster kindly tested it for me and the new version does not crash with Lectrote 1.5.3 on the Mac.