#4859 closed defect (fixed)
LURE: The ScummVM crashes repeatedly
| Reported by: | SF/tony525 | Owned by: | dreammaster |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Lure |
| Version: | Keywords: | ||
| Cc: | Game: | Lure of the Temptress |
Description
The ScummVM always seems to crash after loading the saved game after you enter the room on the right, so the game can't be completed.
This is the GOG.com version of the game and the ScummVM that comes with the game is 0.12.0 (2008-08-31).
Thanks for your help.
Ticket imported from: #2985587. Ticket imported from: bugs/4859.
Attachments (1)
Change History (13)
by , 14 years ago
comment:1 by , 14 years ago
| Summary: | The ScummVM crashes repeatedly → LURE: The ScummVM crashes repeatedly |
|---|
comment:3 by , 14 years ago
| Owner: | set to |
|---|
comment:4 by , 14 years ago
Tried this with : ScummVM 1.2.0svn48643 (Apr 12 2010 22:01:52) Features compiled in: Vorbis FLAC MP3 ALSA RGB zLib FluidSynth on Linux x86-32.
I don't get a segfault, but valgrind reveals the following memory access errors when you load the savegame, which are probably responsible for the crash on Windows. Should fix for v1.1.1 : ==32075== Invalid read of size 2 ==32075== at 0x80B58FC: Lure::Hotspot::showMessage(unsigned short, unsigned short) (endian.h:172) ==32075== by 0x80B6A8C: Lure::Hotspot::actionPrecheck(Lure::HotspotData*) (hotspots.cpp:948) ==32075== by 0x80B82D1: Lure::Hotspot::doOperate(Lure::HotspotData*) (hotspots.cpp:1429) ==32075== by 0x80B869C: Lure::Hotspot::doAction(Lure::Action, Lure::HotspotData*) (hotspots.cpp:1269) ==32075== by 0x80B98FE: Lure::Hotspot::doAction() (hotspots.cpp:1239) ==32075== by 0x80BA1FA: Lure::HotspotTickHandlers::standardCharacterAnimHandler(Lure::Hotspot&) (hotspots.cpp:2645) ==32075== by 0x80BAAE1: Lure::HotspotTickHandlers::jailorAnimHandler(Lure::Hotspot&) (hotspots.cpp:3208) ==32075== by 0x80AE2C5: Lure::Hotspot::tick() (hotspots.cpp:477) ==32075== by 0x80AC698: Lure::Game::tick() (game.cpp:92) ==32075== by 0x80AC73F: Lure::Game::nextFrame() (game.cpp:125) ==32075== by 0x80AC9EA: Lure::Game::execute() (game.cpp:182) ==32075== by 0x807F4A3: Lure::LureEngine::go() (lure.cpp:160) ==32075== Address 0x65efee8 is 0 bytes after a block of size 1,168 alloc'd ==32075== at 0x402582E: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==32075== by 0x80BDF58: Lure::MemoryBlock::MemoryBlock(unsigned int) (memory.cpp:52) ==32075== by 0x80BE03E: Lure::Memory::allocate(unsigned int) (memory.cpp:32) ==32075== by 0x80A78A5: Lure::Disk::getEntry(unsigned short) (disk.cpp:196) ==32075== by 0x8085D66: Lure::Resources::reloadData() (res.cpp:360) ==32075== by 0x8085F9E: Lure::Resources::Resources() (res.cpp:46) ==32075== by 0x807FB71: Lure::LureEngine::init() (lure.cpp:83) ==32075== by 0x808061C: Lure::LureEngine::run() (lure.h:100) ==32075== by 0x80565CD: runGame(PluginSubclass<MetaEngine> const*, OSystem&, Common::String const&) (main.cpp:209) ==32075== by 0x8056F76: scummvm_main (main.cpp:382) ==32075== by 0x8053451: main (main.cpp:65) ==32075== ==32075== Conditional jump or move depends on uninitialised value(s) ==32075== at 0x80B5914: Lure::Hotspot::showMessage(unsigned short, unsigned short) (hotspots.cpp:773) ==32075== by 0x80B6A8C: Lure::Hotspot::actionPrecheck(Lure::HotspotData*) (hotspots.cpp:948) ==32075== by 0x80B82D1: Lure::Hotspot::doOperate(Lure::HotspotData*) (hotspots.cpp:1429) ==32075== by 0x80B869C: Lure::Hotspot::doAction(Lure::Action, Lure::HotspotData*) (hotspots.cpp:1269) ==32075== by 0x80B98FE: Lure::Hotspot::doAction() (hotspots.cpp:1239) ==32075== by 0x80BA1FA: Lure::HotspotTickHandlers::standardCharacterAnimHandler(Lure::Hotspot&) (hotspots.cpp:2645) ==32075== by 0x80BAAE1: Lure::HotspotTickHandlers::jailorAnimHandler(Lure::Hotspot&) (hotspots.cpp:3208) ==32075== by 0x80AE2C5: Lure::Hotspot::tick() (hotspots.cpp:477) ==32075== by 0x80AC698: Lure::Game::tick() (game.cpp:92) ==32075== by 0x80AC73F: Lure::Game::nextFrame() (game.cpp:125) ==32075== by 0x80AC9EA: Lure::Game::execute() (game.cpp:182) ==32075== by 0x807F4A3: Lure::LureEngine::go() (lure.cpp:160)
comment:5 by , 14 years ago
I've identified the immediate cause of the problem - the problem is that the Skorl is trying to show a puzzled floating bubble, but it isn't in the list of characters that are expected to show messages, so the old list scan overran the end and caused a crash. I've changed the code to handle this situation.
The secondary problem is why the Skorl was trying to show the puzzled message. Apparently, it's script was somehow corrupted so that it went to room 42 (the cellar), but was attempting to 'operate' an item which is in room #28. I'll have to do some further analysis to see if I can replicate the problem that causes this.
comment:6 by , 14 years ago
PS: It would help if you could tell me what sequence you used to get the Skorl moving - such as if you talked to Minnow, and what option you used on him.
comment:7 by , 14 years ago
I haven't tried using any objects on Skorl. What I've done is that I've talked to Minnow in the cellar. I told him: -that I've come for Selena -and that he should go tell the big Skorl that there's someone in the basement.
Then I went upstairs in hid in the left room that leads to the balcony where I could hear the Minnow tell the Skorl my story. Then I went back and when I try to go to the room on right the game crashes.
It crashes no matter if I pick any objects in the cellar or not.
Thanks for your help!
comment:8 by , 14 years ago
tony525 : You should be able to check that this has solved the problem for you by testing with a nightly build i.e. http://www.scummvm.org/downloads/#SVN specifically http://www.scummvm.org/downloads/scummvm-win32.exe
comment:9 by , 14 years ago
I've tried the new version and it seems to work fine now! I've managed to get to the room with the winch without a problem... Cool!
Thanks! You guys rock!! :)
comment:10 by , 14 years ago
| Status: | new → closed |
|---|
comment:11 by , 14 years ago
I did some further examination to see if I could replicate the problem with the corrupted NPC schedule that caused the error in the first place, but haven't been able to replicate it. It's probable that tony525 simply used the existing 'corrupt' savegame created with the 0.12 release with the newer versions, rather than replying from scratch.
As such, I'm content to leave this closed, since the immediate cause of the crash has been verified to have been fixed, and all the various changes since 0.12 may have resulted in the original cause having also been fixed.
comment:12 by , 14 years ago
| Resolution: | → fixed |
|---|
The savegame where the ScummVM crashes