SCI: LSL6HIRES-CD: Crash when dialing phone in Larry's room

[Mataniko]

In the beginning of the game, after going to your room and turning on the faucet in the bathroom, trying to call 76 on the phone crashes the game with the following error:

Error: Trying to dereference pointer 0015:03b8 to inappropriate segment!

ScummVM 1.10.0git3727-gea6eebca09 (May 11)
Game language: English
Game version: HIRES CD
Platform: Win32

[Mataniko]

Exit bathroom and dial 76 on the phone.

[Mataniko]

This also happens when dialing 75, with a slightly different error:

Error: Trying to dereference pointer 0015:035d to inappropriate segment!

[Mataniko]

This looks to be caused by the segment manager trying to dereferencing a string in an object that has been cloned from another object, and one of them has been deallocated. In this case our nameReg segment is 21 and the obj segment is 105.

[csnover]

Just to recap, while I am working on a more ideal solution than to just ignore name selectors in SegManager::getObjectName that point to objects in CloneTable:

In LSL6hires there is an unnamed instance of LarryTalker in script 610. The name selector for this unnamed instance is set by game scripts to a reference to a dynamically created Str object.

When parts of the engine call getObjectName on this unnamed instance, an invalid dereference error occurs because getObjectName expects that the name property is either null or points to a string (either from a Script or from ArrayTable), but in this case it is pointing to an object in CloneTable.

Since the purpose of getObjectName is really to identify objects by their original names (as defined in source scripts), I am working on changing the way that retrieving the object’s name reference works so that it does not get changed at runtime. (Currently, the name selector is read out of the object’s _variables, so when a game script sets its name selector, getObjectName gets the new one.)

This change should also allow us to get rid of the Torin script 64000 workaround in getObjectName, since that was caused by a similar problem (a File object with its name set to a dynamic string, which was deleted while the File object was still active).

One (temporary) downside of this change will be that since workarounds rely on object names, some of them may need to be fixed up since they could be matching a dynamic name value which will no longer exist.

[csnover]

Thanks again for your report, and your efforts debugging to help isolate the problem!

The fix described in the previous comment has (finally) been implemented in 49173300385f902ca29d187fd7d2ac6e9eaeea61 and will be available in daily builds 1.10.0git-3297 and higher.