#1314 closed defect (fixed)
FOA: Assertion failed crash at lava pit
| Reported by: | SF/zerryk | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Indiana Jones 4 |
Description
Version: FOA, PC, English, no talkie, Atlantis.001 file size 9679627 B, CRC32 B13F9FC5
Description: Load attached saved game, send Indy with Sophia to the lower tunnel. When they are inside and a new room should appear, ScummVM crashes with the following message:
Assertion failed: searchin, file scumm/resource.cpp, line 2288
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
Tested with both the latest CVS build 2003-11-05 and the latest stable version 0.5.1, win32. The attached debug report comes from the latest CVS build. I didn't know if it works in older ScuummVM because of different savegame format.
I can repeat the crash from some previous saves but I didnt examine it more thoroughly yet, I played Atlantis in ScummVM for the first time...
Ticket imported from: #847805. Ticket imported from: bugs/1314.
Attachments (2)
Change History (15)
by , 20 years ago
| Attachment: | atlantiscrash.zip added |
|---|
comment:2 by , 20 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Indiana Jones 4 |
comment:3 by , 20 years ago
| Summary: | Atlantis: Assertion failed crash at lava pit → FOA: Assertion failed crash at lava pit |
|---|
comment:4 by , 20 years ago
Crashes with another savegame (my own), too. The last line in the error log is: getResourceAddress(FlObject,1) == NULL That hints at a problem with the global objects code. It would be extremly useful to have a savegame just before one gets to the inner circle room (i.e. just before you activate the digging machine etc.).
comment:5 by , 20 years ago
Here is the savegame (BeforeDig.zip), the only thing to do is to insert an orichalcum.
comment:6 by , 20 years ago
Very strange, this thing. Assigning to Ender to make him aware of it. Maybe he has a bright idea...
I am a bit confused, though, I wasn't quite aware that FlObjects are used in pre-V6 games already...?!?
comment:7 by , 20 years ago
| Owner: | set to |
|---|---|
| Priority: | normal → high |
comment:9 by , 20 years ago
A stacktrace:
#0 Scumm::findResource(unsigned, unsigned char const*) (tag=1329744205, searchin=0x0) at scumm/resource.cpp:2279 #1 0x000345d8 in Scumm::ScummEngine::getOBIMFromObject(Scumm::ObjectData const&) (this=0x2121f4, od=@0x33e89a0) at scumm/ object.cpp:971 #2 0x00032e34 in Scumm::ScummEngine::drawObject(int, int) (this=0x2925000, obj=0, arg=0) at scumm/object.cpp:419 #3 0x00032c20 in Scumm::ScummEngine::drawRoomObject(int, int) (this=0x4f42494d, i=0, arg=1611924) at scumm/ object.cpp:353 #4 0x00032d54 in Scumm::ScummEngine::drawRoomObjects(int) (this=0x2925000, arg=0) at scumm/object.cpp:371 #5 0x0002166c in Scumm::ScummEngine::redrawBGAreas() (this=0x2925000) at scumm/gfx.cpp:790 #6 0x00011284 in Scumm::ScummEngine::scummLoop(int) (this=0x2925000, delta=43208704) at scumm/scummvm.cpp:1499
comment:10 by , 20 years ago
Oops, that stacktrace was made with optimizations on, and contained wrong information. A proper one looks like this:
#0 Scumm::findResource(unsigned, unsigned char const*) (tag=1329744205, searchin=0x0) at scumm/resource.cpp:2280 #1 0x00049df4 in Scumm::ScummEngine::getOBIMFromObject(Scumm::ObjectData const&) (this=0x2969000, od=@0x342c9a0) at scumm/ object.cpp:972 #2 0x000479ec in Scumm::ScummEngine::drawObject(int, int) (this=0x2969000, obj=56, arg=0) at scumm/object.cpp:420 #3 0x000476c0 in Scumm::ScummEngine::drawRoomObject(int, int) (this=0x2969000, i=56, arg=0) at scumm/object.cpp:353 #4 0x00047860 in Scumm::ScummEngine::drawRoomObjects(int) (this=0x2969000, arg=0) at scumm/object.cpp:371 #5 0x00028c60 in Scumm::ScummEngine::redrawBGAreas() (this=0x2969000) at scumm/gfx.cpp:790 #6 0x00012a2c in Scumm::ScummEngine::scummLoop(int) (this=0x2969000, delta=6) at scumm/scummvm.cpp:1499
So it dies while trying to draw object 56, in room 55.
comment:11 by , 20 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:12 by , 20 years ago
Fixed in CVS! Quite a nasty bug... the problem was with findLocalObjectSlot() and how it is used... findLocalObjectSlot searches for an available local object slot (as the name implies), and for this only checks obj_nr of each slot... problem is, if that slot still has the flObject flag set, it won't be reset. This results in objects being incorrectly flagged as flObjects.
Mind you, I have no idea how that flObject bit got set in the first place. But however that was, I added a memset to findLocalObjectSlot() which will just zero out the whole object slot before returning it!
comment:13 by , 20 years ago
I'll still look into it - it may be some hitherto unnoticed gunk left over from the flObjects rework I done quite a while ago.
Saved game and debug report