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.

[bluegr]

This is indeed a saved game with a lot of corrupted data, so the issue could be caused by this fact. We have recently added initialization to class members in SCUMM, so such issues will no longer show up, hopefully.

Thus, I'm lowering the priority of this one - people should no longer experience such issues, so this should no longer be a release blocker.

[bluegr]

There's not much that can be done here - the saved game is corrupted, and we've ensured that people hopefully won't face such corruptions in future playthroughs.

Closing as outdated

[wojnarabc]

It still appears in version 2.9.0 of ScummVM on Steam version of the game. Was able to work it around with calling a tram routine mentioned above.

[AndywinXp]

Hi, there's one thing that we really need to know (but people disappears when we ask it): was the playthrough executed ENTIRELY within 2.9.0? Or maybe you started the playthrough on 2.8.1 and then continued on 2.9.0?

[wojnarabc]

Hi, it was 2.9.0 all the way.

[dwatteau]

Hi there,

Thanks for confirming that it was a 2.9.0 game play.

FWIW, Andy asked the team for some full replays using AddressSanitizer and UndefinedBehaviorSanitizer. Here are the results I'm having, so far -- I haven't reached yet the part of the game with the script issue, though.

Setup

Test done on macOS Sequoia 15.3.1, running on a MacBook Air M1 (aarch64). Using the current Git HEAD.

--enable-ubsan --enable-asan --enable-debug --disable-optimizations build with Apple clang 16.0.0.

The Dig is the 2004 French CD release (the one with the Aaron Giles interpreter).

The game is configured this way, for reference:

[dig-fr]
engineid=scumm
enhancements=511
guioptions=sndNoMIDI vga gameOption2 gameOption4 gameOption5 lang_French
dimuse_low_latency_mode=false
description=The Dig (French)
path=/path/to/DIG-FR-2004-aaron-giles
original_gui=true
gameid=dig
language=fr
subtitles=true
aspect_ratio=false

First UBSan issue found

After solving the first puzzle (i.e. asking Miles to get the tools out), a cutscene is triggered when the characters move to the asteroid.

The first UBSan case happens just when the screen is black before loading the new room.

* thread #1, queue = 'com.apple.main-thread', stop reason = Invalid shift base
engines/scumm/actor.cpp:662:21: runtime error: left shift of negative value -10
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior engines/scumm/actor.cpp:662:21 in

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = Invalid shift base
[...]
    frame #5: 0x00000001001789e8 scummvm`Scumm::Actor::actorWalkStep(this=0x00006190003a3980) at actor.cpp:662:21
    frame #6: 0x0000000100170e40 scummvm`Scumm::Actor::calcMovementFactor(this=0x00006190003a3980, next=0x00006190003a3d58) at actor.cpp:575:9
    frame #7: 0x000000010018e420 scummvm`Scumm::Actor::walkActor(this=0x00006190003a3980) at actor.cpp:1014:2
    frame #8: 0x000000010019c464 scummvm`Scumm::Actor_v7::walkActor(this=0x00006190003a3980) at actor.cpp:1400:10
    frame #9: 0x000000010016ed88 
[...]

(lldb) frame select 5
frame #5: 0x00000001001789e8 scummvm`Scumm::Actor::actorWalkStep(this=0x00006190003a3980) at actor.cpp:662:21
   659 			return 0;
   660 		}
   661 	
-> 662 		int tmpX = (_pos.x << 16) + _walkdata.xfrac + (_walkdata.deltaXFactor >> 8) * _scalex;
   663 		_walkdata.xfrac = (uint16)tmpX;
   664 		_pos.x = (tmpX >> 16);
   665 	
(lldb) p _pos
(Common::Point)  (x = -10, y = 133)
(lldb) p _walkdata
(Scumm::Actor::ActorWalkData) {
  dest = (x = 212, y = 173)
  destbox = '\x01'
  destdir = -1
  cur = (x = -10, y = 133)
  curbox = '\x01'
  next = (x = 212, y = 173)
  point3 = (x = 32000, y = 0)
  deltaXFactor = 262144
  deltaYFactor = 47233
  xfrac = 0
  yfrac = 0
  xAdd = 0
  yAdd = 0
  facing = 100
}

Second (similar) UBSan issue found nearby

Similar actorWalkStep() UBSan error also happens when moving to some other part of Attila, just after that.

engines/scumm/actor.cpp:666:21: runtime error: left shift of negative value -14
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior engines/scumm/actor.cpp:666:21

(ldb) bt
[...]
    frame #5: 0x00000001001791f0 scummvm`Scumm::Actor::actorWalkStep(this=0x00006190003a3980) at actor.cpp:666:21
    frame #6: 0x0000000100170e40 scummvm`Scumm::Actor::calcMovementFactor(this=0x00006190003a3980, next=0x000000016fdf7100) at actor.cpp:575:9
    frame #7: 0x000000010018e010 scummvm`Scumm::Actor::walkActor(this=0x00006190003a3980) at actor.cpp:1007:7
    frame #8: 0x000000010019c464 scummvm`Scumm::Actor_v7::walkActor(this=0x00006190003a3980) at actor.cpp:1400:10
    frame #9: 0x000000010016ed88 scummvm`Scumm::ScummEngine::walkActors(this=0x0000000124d44800) at actor.cpp:478:16
    frame #10: 0x000000010131e87c
[...]

(lldb) frame select 5
frame #5: 0x00000001001791f0 scummvm`Scumm::Actor::actorWalkStep(this=0x00006190003a3980) at actor.cpp:666:21
   663 		_walkdata.xfrac = (uint16)tmpX;
   664 		_pos.x = (tmpX >> 16);
   665 	
-> 666 		int tmpY = (_pos.y << 16) + _walkdata.yfrac + (_walkdata.deltaYFactor >> 8) * _scaley;
   667 		_walkdata.yfrac = (uint16)tmpY;
   668 		_pos.y = (tmpY >> 16);
   669 
(lldb) p _pos
(Common::Point)  (x = 160, y = -14)
(lldb) p _walkdata
(Scumm::Actor::ActorWalkData) {
  dest = (x = 209, y = 105)
  destbox = '\x01'
  destdir = -1
  cur = (x = 160, y = -14)
  curbox = '\x06'
  next = (x = 160, y = 16)
  point3 = (x = 32000, y = 0)
  deltaXFactor = 0
  deltaYFactor = 131072
  xfrac = 0
  yfrac = 0
  xAdd = 0
  yAdd = 0
  facing = 180
}

I can't say whether these UBSan errors may be related to the issue above. I haven't encountered any other ASan/UBSan error for now; but I have a few other hours of game play left to do. I'll update my findings.

@AndywinXp: As usual, feel free to ping me over Discord if you need more debugging info or such :)

I'm saving the game every few minutes, so I also have a lot of savegames to share if necessary.

[dwatteau]

So, as a follow-up to my previous test...

The UBSan errors above have been fixed by commit b5451ca5a1e6957d12eb4b44ca769031de2fe865.

I continued my gameplay of the French release with my --enable-debug --disable-optimizations --enable-asan --enable-ubsan 2.9.0git build (still having the previous Actor::actorWalkStep() code for negative values).

I managed to complete that part where Boston fights Brink at the end, without any further issue (whether I was coming from the light bridge or from the tram route). I have around 70 saves from that gameplay, in case someone needs to study them.

So, so far: can't reproduce the issue with a completely new gameplay on 2.9.0git (unless a particular game setting, game action or particular compiler/environment is required to trigger it).

On the other hand, I loaded these new saves from a ThreadSanitizer build, and there, multiple issues were reported. I'm attaching the TSan logs in case they report something important.

[dwatteau]

TSan warnings when loading attached dig-fr.s67 save

[dwatteau]

dig-fr.s67 save