Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#1314 closed defect (fixed)

FOA: Assertion failed crash at lava pit

Reported by: SF/zerryk Owned by: fingolfin
Priority: high Component: Engine: SCUMM
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)

atlantiscrash.zip (25.9 KB ) - added by SF/zerryk 17 years ago.
Saved game and debug report
BeforeDig.zip (16.7 KB ) - added by SF/zerryk 17 years ago.
Savegame before activating dig machine

Download all attachments as: .zip

Change History (15)

by SF/zerryk, 17 years ago

Attachment: atlantiscrash.zip added

Saved game and debug report

comment:1 by SF/zerryk, 17 years ago

errata - the tested build was 0.5.5cvs, built on Nov 23 2003 21:03:56

comment:2 by SF/zerryk, 17 years ago

Component: Engine: SCUMM
Game: Indiana Jones 4

comment:3 by fingolfin, 17 years ago

Summary: Atlantis: Assertion failed crash at lava pitFOA: Assertion failed crash at lava pit

comment:4 by fingolfin, 17 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.).

by SF/zerryk, 17 years ago

Attachment: BeforeDig.zip added

Savegame before activating dig machine

comment:5 by SF/zerryk, 17 years ago

Here is the savegame (BeforeDig.zip), the only thing to do is to insert an orichalcum.

comment:6 by fingolfin, 17 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 fingolfin, 17 years ago

Owner: set to SF/ender
Priority: normalhigh

comment:8 by SF/ender, 17 years ago

I'll look into this next week - no bright ideas yet :)

comment:9 by fingolfin, 17 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 fingolfin, 17 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 fingolfin, 17 years ago

Owner: changed from SF/ender to fingolfin
Resolution: fixed
Status: newclosed

comment:12 by fingolfin, 17 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 SF/ender, 17 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.

Note: See TracTickets for help on using tickets.