SCI: Crash in Island of Dr. Brain robot maze puzzle

[eriktorbjorn]

This happened while trying to solve the robot maze puzzle in The Island of Dr. Brain. I was using the Android version, 2.7.0.5. I have no tried to reproduce it yet.

From what I remember of what I did, I sent the robot through the maze to pick up the first secret crate. I was using the good chip. I accidentally dropped the crate one step before the exit, so I amended the program and sent the robot through the maze again. (Apparently I didn't have to do that, because the crate was gone and the object was still lying near the exit, but I didn't know that.)

While waiting for the robot to finish, not really paying attention to where it was, the game suddenly crashed to the debug console:

Judging by the SCI backtrace, it ran into some sort of infinite recursion, and that's why it ran out of stack?

[m-kiewitz]

Yes, you ran out of stack.
Something calls itself over and over, wouldn't be the first time.
Endless ::cue'ing.

You should probably be able to reproduce this w/ the original interpreter and doing so would be helpful. I'm not sure what the original interpreter does in this situation. Either locks up or exits to DOS.

I assume it's a script bug.

[eriktorbjorn]

You should probably be able to reproduce this w/ the original interpreter and doing so would be helpful.

That may take a while. The puzzle appears late in the game, and puzzles are randomized. I'll try to find some time to attempt it, but it probably won't be this week.

[m-kiewitz]

I should be able to create a script for you to jump to that puzzle room.
or maybe I even got saved games somewhere...

[eriktorbjorn]

That sounds like it would be very useful indeed!

[m-kiewitz]

to patch the game:
extract 140.hep by entering "diskdump heap 140" inside debugger console

edit that file with a hex-editor
look for the sequence:
000005e0: 00 00 ff ff 0a 00 00 00-00 00 00 00 8c 00 ff ff ................
000005f0: 00 00 00 00 a0 00 00 00-82 00 00 00 00 00 00 00 ................

The SECOND a0 00 is the room number to the north. You have to figure out the destination room number and change that value accordingly.

Now I'm not sure which file name convention the original Sierra interpreter needs. It may be 140.hep

You should be able to use that too for the other bugs.
You can figure out the current room number by entering the command "room", but sometimes that info may be wrong, I'm not sure. I can't load all my old saved games, because of some new assert()s.

[m-kiewitz]

140 is the very first room after the copy protection btw.
Of course some puzzles may need items in your inventory. if they do, that would be a problem.

[m-kiewitz]

You will have to restart the game every time you make a change like that.
Saved games will still jump to the original room.
This means you will have to solve the very first puzzle multiple times.

If this is not acceptable/bothersome, I can create a different patch, which should then work every time even when you load a saved game.

[eriktorbjorn]

Thanks, but I decided after reading your description that it was probably less error-prone to just play through the game up to that point on Novice level. (I think you can change difficulty at any time?)

I haven't yet tried to reproduce the bug, though.

[eriktorbjorn]

I haven't yet been able to reproduce this in DOSBox. Sometimes I really dislike randomized puzzles...

[m-kiewitz]

Maybe it's just one special RNG case.
Or maybe it's recursive according to how often you tried?!
Did you try to solve the puzzle 10+ times when it crashed?

[eriktorbjorn]

I don't remember, but I don't think I was trying to do more than just get through the puzzle. And if I was playing it on the highest difficulty (I think I was), I was probably still on either the first or second chip.

[deckarep]

Hello hopefully this is just some added help:

For my copy of the game:

Running The Island of Dr. Brain (DOS/English)
resource.000: b3acd9b9dd7fe53c4ee133ac9a1acfab
resource.map: 2388efef8430b041b0f3b00b9050e4a2

I was able to verify the room with this puzzle is room 300 and script: 320 or programmer.sc which has this robot puzzle game.

The room loads that script at some point and in there is the robot:cue method which has a condition clause that can call cue on itself again. The riddle though is how the game gets into such a state where this becomes a stack overflow...

Hopefully this saves someone some time or trouble in the continued investigation.

[sluicebox]

Fixed in ​https://github.com/scummvm/scummvm/commit/b7522b2bb9f851265de441e1828a5a1dd52c10af

This one was a lot of fun.

To reproduce:

1. Program the robot to drop a piece on the start position
2. Program the robot to leave the start space and collide with a wall
3. Robot will collide with a wall, reverse course, and collide with the piece
4. The second collision is unexpected and crashes

I've attached a save that's in this state. Use the cartridge and click Go to reproduce.

This is not an infinite recursion bug, this is a stack underflow bug. Our validate_variable function allows a lot of nonsense through, and in this case the VM happily served OOB process memory to the script without even logging it. Those undefined values just happened to cause infinite recursion.

(There is an unrelated non-fatal bug in the maze involving floor pieces. When picking up a piece, the tile is still an obstacle until the piece is dropped. This isn't noticeable when picking up a piece from a wall tile, but when picking up a dropped piece from a floor tile, the robot will collide with an invisible obstacle if moved onto it.)