Opened 16 years ago

Closed 16 years ago

Last modified 16 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 16 years ago.
Saved game and debug report
BeforeDig.zip (16.7 KB ) - added by SF/zerryk 16 years ago.
Savegame before activating dig machine

Download all attachments as: .zip

Change History (15)

by SF/zerryk, 16 years ago

Attachment: atlantiscrash.zip added

Saved game and debug report

comment:1 by SF/zerryk, 16 years ago

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

comment:2 by SF/zerryk, 16 years ago

Component: Engine: SCUMM
Game: Indiana Jones 4

comment:3 by fingolfin, 16 years ago

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

comment:4 by fingolfin, 16 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, 16 years ago

Attachment: BeforeDig.zip added

Savegame before activating dig machine

comment:5 by SF/zerryk, 16 years ago

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

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

Owner: set to SF/ender
Priority: normalhigh

comment:8 by SF/ender, 16 years ago

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

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

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

comment:12 by fingolfin, 16 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, 16 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.