LSL6 break to debugger when calling bad numbers

[RayKoopa]

• ScummVM 2.7.0git75-g8b94209d365 (Jun 7 2022 09:02:26)
• Game language: English
• Game version: Hi-Res 1.000.000
• Windows 11 21H2 10.0.22000.675

Steps to "reproduce" (seems to happen randomly, however):

• Repeatedly call a wrong number with Larry's room phone which generates a generic "bad number" reply.
• The game may break into the debugger stating:

  ERROR:
  parameter 0: 0000:0000 (null, integer), should be reference
  [VM] kArrayDuplicate: signature mismatch in method Print::addTitle (room 620, 
  script 64921, localCall ffffffff)!
  

Since this seems to happen randomly, I can only provide context which I believe is required to trigger it:

• Ensure text display is on.
• May require the text display to have scrolled away a few lines.
• May not require usage of easter egg phone number (they're listed ​here if you want to try them).
• The final problematic always seems to be one creating a generic "bad number" reply (there are 2, one from the narrator, one from the phone system).

I captured one attempt succeeding in breaking the game ​here though I also had it happen with far less "setup" and calls required (in fact, I stumbled upon it by random):

I also cannot reproduce it in lores. It should be noted that the telephone behaves very different for some numbers in lores, especially "Long Distance" or the easter egg calls.

I tried to reproduce this in DOSBox, but also couldn't make it happen.

[RayKoopa]

Add context on scrolled away lines.

[m-kiewitz]

I tried to reproduce this in DOSBox, but couldn't make it happen.

Just fyi, these signature checks that we do internally are safety checks from our side. Original SCI did none of that. When signature checks fail, it's typically script bugs, which can cause all sorts of weird issues down the line, which is the cause why we are doing them.

For example some kernel calls in SCI take 2 parameters. And a script calls it with one 1 parameter. Or a kernel call is supposed to get 2 references, but instead gets 1 reference and one string, which would be nonsense. That will get caught by the signature check. Sierra's SCI compiler didn't seem to do much safety checking.

We also do checks for reads on uninitialized variables, which SCI also didn't care about and which caused random errors in some games. Some games even depend on a certain state of uninitialized variables. Our memory system works differently and initializes variables, so these script bugs caused a few issues in our SCI and were very hard to track down (we didn't have these checks in place originally).

In this case the kernel call is kArrayDuplicate, which is supposed to get a valid reference, but in this case it gets a null reference (a reference pointing to nothing), which should never be the case.

[RayKoopa]

Thanks for the explanation. I supposed it was some kind of "strictly incorrect behavior" only caught by ScummVM, yet hoped to notice any of the side effects in DOSBox (maybe even a crash) to confirm the call is also done incorrectly there.

Once I see it happening again, is there a command or something with which I could gather more information on the incorrect call, which could help fixing it?

[m-kiewitz]

360p Video

[m-kiewitz]

Replying to RayKoopa:

Thanks for the explanation. I supposed it was some kind of "strictly incorrect behavior" only caught by ScummVM, yet hoped to notice any of the side effects in DOSBox (maybe even a crash) to confirm the call is also done incorrectly there.

Once I see it happening again, is there a command or something with which I could gather more information on the incorrect call, which could help fixing it?

You can't do much about it yourself, unless you know ins and outs of SCI and in case you can compile ScummVM yourself.
There is a workarounds.cpp in the ScummVM SCI source code which contains these special situations / script bugs. There are also tons of script patches, where we fix bugs on the fly.

In the workaround.cpp tables you can enter what ScummVM is supposed to do in that situation, which is either "still call" (call the kernel call anyway), "ignore" (don't call) or "fake" (don't call and fake the result that would have come back from the kernel call, some game scripts require specific values coming back), but in the end someone has to go through the LSL6 scripts and figure out what's actually going on and then do a proper fix. You said it happens randomly, which hints at it probably being timing related.

And of course we can never rule out actual interpreter bugs in ScummVM, these may exist as well. This here looks like another script bug to me for now. And in original SCI some of these issues were harmless, others even caused memory corruption, which then in turn may have caused the game to crash 1 hour later or break the state of the game.

[RayKoopa]

Aww, I see, I thought of something like "printing a stack trace" command or anything as I otherwise indeed barely know anything about SCI internals, with the "best" I can do being looking at decompiled SCI scripts of a game and then trying to understand it's prefix-ish syntax :o)

(I guess making Larry do a bad call caused the game to make a bad call... hilarious.)

[m-kiewitz]

You can do a "bt", which is a backtrace.

In the end though just the full signature check error message should be enough (including saved game, which you already supplied plus a way to reproduce it, which you also supplied)

Yes, quite hilarious. If I remember correctly most of the earlier SCI games were better play tested than the latter. In the case of LSL6, it's also important to know if a certain bug happens in LSL6 hires only, or in both versions. If you own both, it would be great if you could check the low res version as well for this bug. low res LSL6 used SCI1.1, while the hires version used what we call SCI32. The scripts of these two are not the same.

[RayKoopa]

Good call, I added lo-res behavior (e.g., can't trigger the bug there. Phone behaves very different there indeed).

[sluicebox]

Fixed in ​https://github.com/scummvm/scummvm/commit/50fec97f8a74e95e9b710f70fcc03fe65c786cec

This occurs when text is enabled and you talk to the operator after talking to someone else on the phone. For example, call "72" to talk to the "Bell Desk" voice and then call "5555555". There's a 50% chance of getting the operator ("The number you have dialed...")

This is a script bug in the hi-res version. It doesn't seem to crash the original, but that looks like luck. The original interpreter casts zero to a pointer and then uses it.

[RayKoopa]

Great! I'd like to test it, but the daily build seemingly failed, it's a 0KB download :O

[RayKoopa]

Great, fixed in my test with the latest build :D
(I also finished playing through the game, and I haven't found other bugs yet. Thanks for all the work! Only thing remaining is the music volume issue I created a while ago that I still don't know how to properly reproduce).