weewonder / garglk

Automatically exported from code.google.com/p/garglk
Other
0 stars 0 forks source link

bocfel: I-0 very crash-prone #144

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Download Adam Cadre's I-0 from http://adamcadre.ac/content/I-0.zip
2. Start the game.
3. >restart
4. >take purse

What is the expected output? What do you see instead?
Game crashes with the error "@save_undo called inside of an interrupt"

What version of the product are you using? On what operating system?
Latest svn.

Please provide any additional information below.

I'm not sure if this is due to the game being buggy, or due to bocfel, or both.
The crash doesn't happen with frotz.

During my playing of the game, I got it to crash in other ways in different 
places.

With frotz, I do get this warning when starting the game: "Warning: @get_child 
called with object 0 (PC = b62b) (will ignore further occurrences)"

Original issue reported on code.google.com by saltyho...@gmail.com on 20 Mar 2011 at 8:48

GoogleCodeExporter commented 8 years ago
I wasn't able to recreate the crash under OS X, even when playing through the 
entire game. I will try other systems tomorrow.

Original comment by bcressey@gmail.com on 20 Mar 2011 at 10:15

GoogleCodeExporter commented 8 years ago
I'm using Ubuntu 64bit

Original comment by saltyho...@gmail.com on 20 Mar 2011 at 10:51

GoogleCodeExporter commented 8 years ago
Repro'd under Windows and Ubuntu x64.

Original comment by bcressey@gmail.com on 21 Mar 2011 at 4:44

GoogleCodeExporter commented 8 years ago
Definitely a bug in Bocfel.  It's been fixed in 0.5.4 which has been imported 
into the repository.

This bug was directly related to restarting, so if the other issues happen 
after a restart, see if the latest version in SVN has those fixed, too.  
Otherwise, if you don't mind providing steps to reproduce them, I can track 
them down.

@get_child on object 0 is a bug in the game, but it's the fault of Inform and 
many games contain such errors due to this.  Consequently, interpreters ignore 
these errors, sometimes printing a warning as Frotz does.  In any case, it's 
harmless.

Original comment by cspiegel@gmail.com on 27 Mar 2011 at 11:53

GoogleCodeExporter commented 8 years ago
I didn't write down the exact steps to reproduce the other bugs. I remember 
seeing an assert with a bocfel source filename.

I'll try to replay the game a bit and see if I get it with the non-fixed 
revision.

In the meantime, I think this bug can be closed. Thanks for the help!

Original comment by saltyho...@gmail.com on 27 Mar 2011 at 6:06

GoogleCodeExporter commented 8 years ago
Bocfel is rather strict in its adherence to the standard, so its assertions 
might catch code that generally would be ignored by more lenient interpreters.  
I've special-cased a few of these to be ignored (there's little benefit in an 
interpreter that can't play games), and if there are other common cases where 
games die, I'm more than willing to ease up on restrictions.

Of course, as in the case of this issue, assertions might be triggered by bugs 
in Bocfel, as well.  Feel free to report all assertions you find, and thanks 
for testing!

Original comment by cspiegel@gmail.com on 27 Mar 2011 at 9:30