Opened 14 years ago
Closed 3 years ago
#5294 closed defect (fixed)
MOTHERGOOSE SCI1.1: Crash at the very end
| Reported by: | SF/kuroshiro | Owned by: | sluicebox |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | ||
| Cc: | Game: | Mixed-Up Mother Goose |
Description
Mixed Up Mother Goose (Floppy/Dos/English) ScummVM 1.2.0SVN
At the very end, after you complete the game, it crashes with the message: "Uninitialized read for temp 367 from method sunrise::changeState (script 94, room 94, localCall 3c9)!"
Ticket imported from: #3051163. Ticket imported from: bugs/5294.
Attachments (1)
Change History (13)
by , 14 years ago
| Attachment: | mothergoose-1.000 added |
|---|
comment:1 by , 14 years ago
Fixed, though I don't have this version of mother goose to test it out :(
If you get any further errors, please report them
comment:2 by , 14 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:3 by , 14 years ago
not fixed according to bug #3051525
"It might take a little longer to crash now, though I'm not entirely sure."
comment:4 by , 14 years ago
| Status: | closed → new |
|---|
comment:5 by , 14 years ago
"please just re-open the old bug and don't create new ones."
Just to let you know, not everyone can do that. I can't at least.
comment:6 by , 14 years ago
| Summary: | MOTHERGOOSE: Crash at the very end → MOTHERGOOSE SCI1.1: Crash at the very end |
|---|
comment:7 by , 14 years ago
hmm i just finished the game (seems that i got your version) and it worked for me. I finished the game, end dialog came up, i selected "replay" and it went to the main menu. Could you please try again?
comment:8 by , 14 years ago
| Owner: | changed from to |
|---|
comment:9 by , 14 years ago
Ok, I can confirm that this is now fixed as of r52446, though it definitely wasn't before. Not sure what caused it. Actually, the performance of the whole game in general seems to be significantly improved, with various small errors and glitches vanishing.
comment:10 by , 14 years ago
| Status: | new → closed |
|---|
comment:11 by , 3 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
*CREEEEEAAAAAK* Arise, 11 year old unfixed bug! Arise!!
We have a workaround for this uninitialized read, but it doesn't do anything. The uninit read occurs in a local procedure, but there is no local procedure signature attached to the workaround entry. But that doesn't matter because...
The uninitialized read isn't the bug here, it's just a symptom. This game does a lot of save-slot calculations in its scripts that are incompatible with our virtual-save-slot scheme. We have several script patches and workarounds to deal with this, but they are incomplete. There are other scripts that do this which we don't do anything about. The game can still end up in a state where the global that contains the current save slot number (global 179) receives a SCI save slot, such as 1, instead of our virtual slot 101. That's what causes the uninit read. And even if the uninit read workaround entry were to have an effect, ScummVM would just have crashed a few instructions later when kDeviceInfo(K_DEVICE_INFO_GET_SAVEFILE_NAME) got passed an invalid virtual id.
I'll be auditing the scripts to figure out what to do about the remaining ones that are incompatible with ScummVM virtual save slot numbers.
comment:12 by , 3 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This is now fully fixed in e5951416d4024701315bd7563859436434a31ad5.
The scenario that would still crash was when a new game was started and played all the way through without restoring. The game's save global is now updated when auto-saving in addition to when restoring, so it's now always correct (a virtual id) when there is a save file.
you'll have to solve one puzzle to get to the end -- the ladder is in the crooked man's house