SCUMM: DIG: Error box 29 is out of bounds in ScummVM 2.8.1

[zoltan808080]

I have a problem in The Dig. I'm about to go and talk to Brink (It's the part where Brink tries to fight Low, and accidentally falls over the cliff), but when I go from the cave (The one with the bat-like creatures) to where Brink is, I get an error which says:

ERROR: (105:2013:0x1E630(: box 29 is out of bounds (0,21)!

Maverick_Hunter1900X have the same problem yesterday

I have been able to go and talk to Brink earlier in the game, without any problems. It only happens when I am about to fight Brink, that this error appears (near from the end of the game)

[antoniou79]

Could you specify which version of the game you're testing with? The saved game's naming suggests it's a French version.

I have tested with the GOG French version (and also the GOG English one) but I am unable to reproduce the issue.

Does the issue happen all the time or just sometimes?

From your saved game what would be the steps to reproduce the bug? For the record, I tried going directly to Brink (no crash), going to get the alien device and then to Brink (no crash), fixing Brink's machine, then leaving and returning to his screen (no crash), and finally fighting him (removing the "eye" from the machine. No crash so far. I have tested with the English and French versions from GOG.

[zoltan808080]

Hi,

You're right, I just tried twice and didn't have the problem! (I had it three times in a row)
I use the French version. The problem occurred when I was in the bat cave (just before Brinks' screen) and rejoined Brinks (during the transition of the two screens)

[AndywinXp]

Can you try using a daily build?

[AndywinXp]

Any news on this?

[AndywinXp]

Closing this as we can't reproduce it in any way and we haven't got a follow-up by the user. If zoltan808080 has more info about how we can reproduce it, I can gladly reopen the ticket. Thanks!

[tomasaschan]

I'm seeing this with the DIG assets from Steam, on ScummVM 2.8.1.

I have a save game where I can, consistently, trigger the error by going to the next room (from the bat cave to Brink's platform, as described in the OP). How do I export that save game file so I can share it with you?

Are there any debug commands I can run in the ScummVM debugger to help figure out what's going on? (I tried mucking around based on what help gave me, but I didn't get much wiser...)

[AndywinXp]

Hi, thanks for your report! First of all: can you use a daily build ​https://buildbot.scummvm.org/#/dailybuilds and tell me if it's still broken?

Yes, please, post your savegame here: you will find it in %appdata%/ScummVM in Windows. The name is something like dig.s**, where ** indicates the savegame slot.

[tomasaschan]

Thanks for the very fast reply! Attached dig-steam-win.s04; the only thing you should need to do to repro is to load that, and move one step into the next location ("platform").

I also found ​https://forums.scummvm.org/viewtopic.php?t=17138 which mentioned, among a bunch of other stuff I haven't tested yet, that going to the base of the tomb spire and calling the tram works around the bug. This did indeed work for me - if, from the save, you first go to the bottom of the spire and call the tram, and then up again, you can progress in the game without a crash.

I have yet to verify whether it works without calling the tram (as someone in that thread mentioned) and whether it works to re-save the game using a daily build of ScummVM. Will take a stab at testing those variants as soon as I finish the game :)

[AndywinXp]

Thank you for the savegame :D I'll let you know if I can reproduce it...

[tomasaschan]

Some more test results!

Versions tested:

• released (2.8.1)
• stable (2.8.1pre403-g24ed5c04709, windows-x86-64-stable-24ed5c04)
• master (2.9.0git6629-g27490d73de1, windows-x86-64-master-27490d73)

Results:

• stable: Still crashes
• master: Still crashes
• released: Just walking down to the tram station at the bottom of the spire avoids the crash. (I have not tested further if walking just part of that path helps.)
• master: Loading the attached save-game-file, then saving it in a new slot (to rewrite from the master version of ScummVM), then trying to progress still crashes
• master: Loading the re-saved game (i.e. after saving to a different slot from master) still crashes

Theory:

Some asset is loaded, or unloaded, when navigating to this spire via Tram, by means of a script that loads when the tram station location is entered. This asset is required by the game when moving into the fight-with-Brink scene, but is not correctly loaded if one navigates to the spire via the light bridges. By walking down to the tram station, some internal game state is put in order to avoid the crash.

[tomasaschan]

(Btw, I don't follow this bug tracker regularly, so not sure how I'll notice if you have further questions for me. My email address is my-first-name.my-last-name@gmail, and my username is my-first-namemy-last-name, so I bet you can figure it out if you need to :))

[antoniou79]

Loading the saved game (dig-steam-win.s04​) in The Dig (English, GOG version and Steam version), will "crash" the game with the above debugger message for me, indeed. I tested with a local msys2/mingw-64 (Windows) build from ScummVM master HEAD (2.9.0git), the recent daily deb build (2.9.0git) (64bit) for Windows and 2.8.1 stable.

But also, in all these ScummVM versions, I get a crash to desktop if I exit the cave from the other pathway (bottom left on the screen). It's a "segmentation fault" error. This is only when loading from the provided saved game.

[AndywinXp]

I can now reproduce it, thanks to the last provided savegame. The symptom is that:

• We start from room 57
• We go to room 105
• As soon as room 105 is loaded, the destination coordinates for the player character become (-1, 411), which correspond to an invalid walkbox identifier (number 29)

As for the cause of this symptom... I'll continue investigating, but this smells like some part of the code is causing memory corruption...

[somaen]

Sounds like something we should fix for 2.9.0

[AndywinXp]

Replayed the entirety of The Dig (english version) on 2.9.0git with Address Sanitizer active. Couldn't reproduce this at all :-(

[eriktorbjorn]

@AndywinXp Do you have a corresponding savegame where the bug doesn't happen? It may be a long shot, but perhaps investigating where they differ will provide a clue.

Assuming you haven't already done that.

[AndywinXp]

I did already debug the "bad" savegame provided here; the difference is that a bunch of the savegame data (most notably the iMUSE state) is corrupted, therefore the game fails to operate normally.

[eriktorbjorn]

Ok. As I said, it was a long shot.

It seems we do write a lot of potentially uninitialized iMUSE data to save files, but I assume this is not what you're talking about. E.g. functions like IMuseDigiTriggersHandler::clearAllTriggers() only initializes some of the data. (It also clears one field of _defers which seems a bit risky to me, but should work as long as DIMUSE_MAX_TRIGGERS and DIMUSE_MAX_DEFERS have the same value.)

[AndywinXp]

Thanks for checking, but the part of iMUSE data being damaged is the attributes array. And probably even more beyond that which is not visible by naked eye.