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

[xbmc50]

Hi, just recently started to play The Dig on ScummVM I _think_ it was 2.9.0 (Confirmed - It was 2.9.0). Few days ago. Then stumbled into this error and updated ScummVM to 2.9.1 and I can confirm that this bug still happens to me too. My files are from GoG version iirc (English).

I added my savegame you can check. Just go directly to Brink to north and game crashes. I can also confirm, thank you very much tomasaschan, that if you just go down the spire and call tram, actually not sure if call is even needed, but after that Brink scene seems to load just fine.

*edit*
Just quickly tested and tram call button hit isn't required. Just go down and back up to Brink and scene plays out normally

Just thought to drop by and drop this save I happened to make just before the bug.

[xbmc50]

Replying to 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?

I can confirm that my version was likely 2.9.0. My install was slightly old, but I'm like 100% sure that I started fresh playthrough just few days ago. Stumbled onto this bug and tried to update ScummVM to 2.9.1. Unfortunately I updated with Choco and didn't take that good look which was the original version, but not even close to old as like 2.8.1, that I'm absolutely certain

*edit*
I can now confirm 100% my playthrough to the save point has been made with 2.9.0. I checked my Chocolatey logs
2025-06-07 14:59:15,730 15916 [DEBUG] - scummvm 2.9.0

[eriktorbjorn]

Perhaps this is already obvious, but the actor with the bad walkdata seems to be Brink. So the problem, whatever it is, has already happened in this savegame unfortunately.

Wild speculation time:

How is Brink moved to room 105? Could it be that his walkdata was valid right before that move, but is now stale? What should - and does - happen to his walkdata when he's moved to a different room like that anyway?

[eriktorbjorn]

I've begun a new playthrough where I've added some debug code just to keep track of Brink. Maybe it'll give an idea.

Assuming that box 29 was valid somewhere, perhaps it also makes sense to put together a list of rooms with that many boxes. See if it's possible to get Brink moved to room 105 from one of them:

• Room 23 (the Nexus) has 39.
• Room 58 (the tomb) has 30.

[antoniou79]

Replying to xbmc50:

Just quickly tested and tram call button hit isn't required. Just go down and back up to Brink and scene plays out normally

Could you check if it would suffice to just go down to the "spire base" scene (the scene you reach from the "plateau/edge" scene) and not the "tram" scene? In my testing with your saved file, and current dev build (2.10.0git) that seems to work as well.

[eriktorbjorn]

One place (but is it the only place?) where Brink gets moved to room 105 is when the sea creature kills the turtle. But there aren't enough walk boxes in that room to leave it at 29 there.

[xbmc50]

Replying to antoniou79:

Replying to xbmc50:

Just quickly tested and tram call button hit isn't required. Just go down and back up to Brink and scene plays out normally

Could you check if it would suffice to just go down to the "spire base" scene (the scene you reach from the "plateau/edge" scene) and not the "tram" scene? In my testing with your saved file, and current dev build (2.10.0git) that seems to work as well.

Yes, you're right. It indeed seems that moving into "spire base" screen is enough. No need to go to the tram screen. Good spot there. I just tried your method twice and both times Brink scene worked without any issues.

Out of curiousity tried to visit just "lens/edge" screen and tomb and go back to Brink and game crashes. So it indeed seems that it's specifically that "spire base" screen where something happens inside game and it begins to work again.

My version is still on 2.9.1

Let me know if I can try something else to help. I try to remember to follow this thread for awhile. Unfortunately I don't seem to find any notification thing here to my shame.

[xbmc50]

I just added save from bit before my previous bug encounter. Because I stumbled into something I think shouldn't happen. So if you open my dig.s03 savegame. I plug out that green alien part and I originally intented to go to Nexus from this location via tram. But then from Nexus if I try to go to Tomb spire to Brink, I can't call the tram. I think it should be possible? This the reason I got to tomb spire via those light paths and game crashes.

I'm not sure if this is related to bug, but at least there's bit more screens in between the bug occurance if you use this save and go via the light paths, which seem to be only option?

[eriktorbjorn]

That's odd, because even if you go to the spire base Brink's walk data isn't set to something sensible until you enter the room where it would previously crash. Have to figure out what causes it to work. Maybe there's simply a script bug?

Another odd thing is that if I try to load the savegame while the intro cutscene is playing, ScummVM complains that it's using different savedatata and crashes. If I skip the cutscene first, I can load the savegame just fine.

[eriktorbjorn]

I can only assume that the entry or exit script in the spire base sets up things for actor 5, but there's too much happening in those scripts for me to wrap my head around it right now. (Possibly ever.)

[eriktorbjorn]

When you leave the spire base, the exit script (exit-54) does this among other things:

[0039] (9D) actorOps.setCurActor(5)
[003E] (9D) actorOps.setWalkSpeed(4,2)

Somehow, don't ask me why, this is enough for the game not to crash when entering the plateau. I've verified this by making (but not committing, of course) a simple debugger command that does the same thing:

bool ScummDebugger::Cmd_Brink(int argc, const char **argv) {
	Actor *a = _vm->derefActorSafe(5, "Brink");
	if (a) {
		a->setActorWalkSpeed(4, 2);
		debugPrintf("OK.\n");
	} else {
		debugPrintf("Fail.\n");
	}
	return true;
}

That also happens while entering the room (room-105-2013), but apparently the crash happens before that.

[antoniou79]

Here's a saved game (dig-1.s62) from my playthrough with ScummVM 2.10.0git on Windows with Dig (GOG, English version). Important note the saved game only works with ScummVM 2.10.0git version, it won't work with ScummVM 2.9.1 since it appears as "invalid version" there.

I made this saved game while playing the game with ScummVM 2.10.0git on February 2025, with a local build from the then master HEAD (with minor unrelated to SCUMM and COMMON local changes).

I was attempting a full playthrough with a dev version of ScummVM to see if I could reproduce this bug. I was playing with "Enable original GUI and menu" and "Fix original bugs" checked, and all other game specific ScummVM launcher options unchecked.

From the point of this saved game, I was going to visit Brink to see if it would trigger the crash (I was attempting various scenarios, and apparently this was attempt number 6).

You can visit Brink after reloading the saved game and it won't trigger the crash.

But the following steps will trigger it (some of the steps may be redundant):

1. Reload the saved game "AttemptSix-f25" (this is soon after finding the "Eye part").
2. Don't go to visit Brink, and instead use the light bridge
3. Go to Cathedral island, and then head in the "lab"
4. Low and Maggie will automatically walk to the bottom of the "lab" where Brink will be waiting. (let them walk all the way down, don't skip this).
5. A cutscene will play (Brink gets all of Low's crystals). You can skip this or let it playthrough (I tried both and the bug is still triggered)
6. (optional) After Brink leaves, click on the "console" and use the Eye part on it.
7. Then walk back to the upper part of the scene and leave (towards "outside")
8. Use the light bridge and go to Tomb island
9. Enter the cave and go to "platform" to find Brink.

This crashes the game with the reported error.

Trying the above steps a few times, it seems that in "step 4" it matters whether you skip the automated walk to the bottom or not. If you skip it, the crash won't be triggered. If you let it play through it will.

Edit: after a few replays, it seems that step 6 is optional (you can keep the Eye part with you). The critical step seems to be "step 4" and not skipping the automated walk to the bottom to trigger whatever it is that makes the crash happen later on. Also, obviously travel exclusively from light bridges, since we established that the "spire base" scene somehow fixes the state.

[xbmc50]

Replying to antoniou79:
...
...

4. Low and Maggie will automatically walk to the bottom of the "lab" where Brink will be waiting. (let them walk all the way down, don't skip this).

...
...

I unfortunately don't have suitable save to test this from my playthrough as I copied over my saves bit too frequently, but I'm sure this statement was "true" on my playthrough. Iirc I didn't try to skip any parts where Maggie was involved to avoid accidentally skipping any dialogue (I think it's actually impossible to do now, but didn't realize it on my playthrough) and at least for sure, if there were any Brink visible in scenes I didn't try to skip character animations and isn't Brink visible the moment you arrive in lab?

[antoniou79]

Replying to xbmc50:

... and isn't Brink visible the moment you arrive in lab?

In the steps above you arrive at the lab from the top exit, so Brink wouldn't be immediately visible even if he were at the bottom level near the device's console. However, as the scene plays out in-game, he's not there when Low and Maggie reach the console. He appears coming from the left side of the screen at that point.

[eriktorbjorn]

I wasn't able to reproduce the crash in my playthrough, even though I used the light bridges to get to the tomb spire and didn't skip anything after Brink appeared in the lab.

However, Brink did get moved to the plateau with walkdata pointing to box 29, just as in the problematic savegame, and since even the workaround of going to the base of the spire simply changes his walk speed, not the walkdata... well, the whole thing seems to be just really fragile, and we should probably do something about it. Which may be as simple as resetting his walkdata to something sensible whenever he gets moved to the plateau?

You can also get him to the plateau with walkdata pointing to box 28 if you hit escape right after using the steel plates in the nexus, but I wasn't able to get it to crash from that either.

[AndywinXp]

In 335da77:

SCUMM: SOUND/DiMUSE: Attempt to fix various data races

Data races reported in ticket #15215:
"SCUMM: DIG: Error box 29 is out of bounds in ScummVM 2.8.1"

[dwatteau]

@AndywinXp: With the same setup as my previous TSan test, here's what I now get after your last commit.

(Still using the earlier dig-fr.s67 attachment, and building with --enable-tsan of course.)

[dwatteau]

New tsan output with dig-fr.s67 and latest commit

[dwatteau]

New TSan output with a new build from commit d83532f82f167adb227214268b0624b67e79e856

[antoniou79]

I just tested restoring a saved game (of my own playthrough in 2.10.0git) from an much earlier point than the one I attached above.

This saved game was before using the last metal plate on the nexus indentation. I reached the point before going to the lab with the Eye part, probably doing some steps differently than before, but this time, no matter if I followed my steps to reproduce the crash or did something different, the crash did not occur.

I am testing with a recent local build of ScummVM 2.10.0git from master HEAD.

So while I can still trigger the crash (and also not trigger it) from my previously attached saved game, I cannot trigger it from another new one I made in this most recent attempt, even if I don't skip the automated walk down the lab.

This seems to align with what eriktorbjorn wrote above.

[eriktorbjorn]

After some more debugging, there doesn't seem to be any differences between the actor data in my savegame and the savegame that crashes. The crash happens when a script calls setActorWalkSpeed().

Further debugging suggests that the relevant difference may be bitvar110. If I force that to be 1 (like it is in the old savegame), my savegame crashes too.

So the question becomes, what does that variable do? When and why is it set?

I can see that it's set by room-105-2011, seemingly at the end of this conversation:

"I've studied all the inscriptions -- Maggie's not the only one who can decipher strange languages! I followed the plans I found, but there's still something missing, and without it the machine won't work. So if you think you can steal my life crystals again, Commander Low, think again! I'll kill you first, and believe me, no one will ever revive you!"

"Actually, you've robbed me twice, and I only robbed you once. So you're still one ahead."

"Don't joke with me!"

"Don't joke with him, Boston."

So this would have to be at some point after Maggie gets rescued from the spider, but before Brink retreats to the plateau for the last time?

[eriktorbjorn]

I've attached one of my savegames (dig.s22) right outside the lab.

If I enter the lab and wait for Brink to steal the crystals and leave, I was not able to reproduce the crash.

If I first went to the plateau to have the conversation described above, and then went back to the lab for Brink to steal the crystals, i was able to reproduce the crash.

In both my tests I used the light bridges rather than the trams to move around.

[eriktorbjorn]

After eefca8bffbc4482461a30a7658ba534f13abb082 I'm no longer able to reproduce the bug. So maybe it's finally gone now?

[antoniou79]

I can confirm that that commit seems to fix my save game too -- I don't get the crash anymore following the steps I described above.

@xbmc50 could you test with a daily build (column "ScummVM latest branch master") and report back if your game is now fixed without the workaround (ie. without going down to the location near the tram) ? ​https://buildbot.scummvm.org/#/dailybuilds

[AndywinXp]

I'm tempted to close this, OP has possibly moved on and I think two confirmations are enough.

[xbmc50]

Replying to antoniou79:

I can confirm that that commit seems to fix my save game too -- I don't get the crash anymore following the steps I described above.

@xbmc50 could you test with a daily build (column "ScummVM latest branch master") and report back if your game is now fixed without the workaround (ie. without going down to the location near the tram) ? ​https://buildbot.scummvm.org/#/dailybuilds

Hi, sorry for late answer. I just briefly tried with latest daily 64bit master branch 90c7b813 and it seems that my save game works in that.

[AndywinXp]

Thank you for confirming! Closing...

[AndywinXp]

In ec98389c:

SCUMM: DIG/DiMUSE: Post-load fix for corrupted savegames

Fixes #16287:

"SCUMM: DIG: Game crashes when moving to another area"

There has been a small wave of corrupted savegames which
were seemingly connected to ticket #15215:

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

In affected savegames, the _attributes array from the iMUSE system
seems to contain byteswapped 32-bit values in a few of the slots,
suggesting some kind of data corruption happening behind the scenes.

While the issue was solved in eefca8b ("SCUMM: (DIG) - fix setActorWalkSpeed"),
there is no guarantee that a previous savegame won't be affected and won't cause
a chain reaction in playDigMusic(), causing an out of bounds array read.

This is a pretty reliable way to detect if the savegame was corrupted.

Hopefully.