Opened 21 months ago

Closed 21 months ago

Last modified 21 months ago

#13554 closed defect (fixed)

LSL6 break to debugger when calling bad numbers

Reported by: RayKoopa Owned by: sluicebox
Priority: normal Component: Engine: SCI
Version: Keywords: original
Cc: Game: Leisure Suit Larry 6

Description (last modified by 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.

Attachments (2)

lsl6hires.002 (45.5 KB ) - added by RayKoopa 21 months ago.
LSL6 - Break to debugger on bad phone call 360p end.mp4 (2.0 MB ) - added by m-kiewitz 21 months ago.
360p Video

Change History (13)

comment:1 by RayKoopa, 21 months ago

Description: modified (diff)

Add context on scrolled away lines.

by RayKoopa, 21 months ago

Attachment: lsl6hires.002 added

comment:2 by m-kiewitz, 21 months ago

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.

Last edited 21 months ago by m-kiewitz (previous) (diff)

comment:3 by RayKoopa, 21 months ago

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?

in reply to:  3 comment:4 by m-kiewitz, 21 months ago

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.

comment:5 by RayKoopa, 21 months ago

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.)

comment:6 by m-kiewitz, 21 months ago

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.

comment:7 by RayKoopa, 21 months ago

Description: modified (diff)

comment:8 by RayKoopa, 21 months ago

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

comment:9 by sluicebox, 21 months ago

Keywords: original added; debugger signature mismatch removed
Owner: set to sluicebox
Resolution: fixed
Status: newclosed

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.

comment:10 by RayKoopa, 21 months ago

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

comment:11 by RayKoopa, 21 months ago

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).

Note: See TracTickets for help on using tickets.