Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#1994 closed defect (fixed)

MI: Jungle scene with monkey (you give banana to) crashes

Reported by: SF/chaosdiscord Owned by: cyxx
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Monkey Island 1

Description

ScummVM Version: 0.7.1
OS: MacOS X 10.3.8
Game: Monkey Island 1 VGA from CD-ROM (DOS version)
Language: English

Using the official 0.7.1 binary. It's otherwise working (played Fate of
Atlantis from start to finish using it.) Played MI1 through arrival at
Monkey Island without problem. Upon arrival moved north into the
Jungle. Clicked on the moving grey dot labelled "monkey." This
takes us to a jungle scene with the monkey. Within a few seconds
(maybe 10) ScummVM exits without any messages or complaints.
Giving the monkey the banana triggers the problem, as does simply
waiting and watching the monkey run around.

Save file is in the jungle/overland map. Can reproduce by clicking on
the monkey (near the bottom center), thus entering the detailed jungle
scene. Then wait.

Running from the command line, I get the following:

Looking for monkey
Trying to start game 'Monkey Island 1'
WARNING: FlacInputStream: could not create an Audiostream from
File track17.fla!
WARNING: FlacInputStream: could not create an Audiostream from
File track24.fla!
sound/audiocd.cpp:111: failed assertion `index >= 0'
Abort trap

I have the flac converted files in the Monkey Island directory, but they
weren't working. So I'm using the original CD for audio. Deleteing the
unnecessary .fla files eliminated the warnings and seemed to
eliminate the crash.

Ticket imported from: #1181979. Ticket imported from: bugs/1994.

Attachments (1)

monkey.s12 (12.4 KB ) - added by SF/chaosdiscord 15 years ago.
Save game near crash point

Download all attachments as: .zip

Change History (16)

by SF/chaosdiscord, 15 years ago

Attachment: monkey.s12 added

Save game near crash point

comment:1 by eriktorbjorn, 15 years ago

Were you able to play those FLAC files in any other media
player? Looks like ScummVM considered them to be invalid.

Of course, it still shouldn't trigger the assertion like that...

comment:2 by fingolfin, 15 years ago

Well, essentially, ScummVM isn't very generous when you feed broken
data files to it. If you do that, as was the case here, it seems, then
crashes can happen. It can crash if you feed it fake 000.LFL files, too, for
example.

comment:3 by cyxx, 15 years ago

By looking at the code, I saw that a track can cached even
if no compressed files are found. I think this should cause
trouble. For example, if a call to getCachedTrack is made,
the track isn't in cache and no compressed file is found, we
will end up with something like :
_track_info[i] == NULL
_cached_tracks[i] == trackNum
Next time getCachedTrack() will be called with the same
track number, the first loop will return -1 and the assert
in updateCD() will get triggered...

Anyway, I just committed some code which should fix this.

comment:4 by fingolfin, 15 years ago

What is the status of this item?

comment:5 by fingolfin, 15 years ago

Owner: set to cyxx
Summary: Jungle scene with monkey (you give banana to) crashesMI: Jungle scene with monkey (you give banana to) crashes

comment:6 by cyxx, 15 years ago

I committed some code which *should* prevent crashes when
playing with invalid / unreadable music files.
But it would be nice if the bug submitter could test the CVS
version with his invalid files and report us if what I did
helps...

comment:7 by SF/chaosdiscord, 14 years ago

I got around to digging up the flac files in question (I'd
deleted them) and can again reproduce the problem. I get
the same behavior without the CD (and discovered that I get
some, but not all, of the music). Now that I've got the
flac files again I'll 1. check to see if they're valid (I'll
see if XMMS likes them) and 2. Test to see if CVS works.
I'm not a Mac guy and the Mac in question isn't mine, so it
may take a bit. I'd use a developer build, but it looks
like the last MacOS dmg file is over a month old.

comment:8 by fingolfin, 14 years ago

I can provide you with a newer build, feel free to email me.

comment:9 by SF/chaosdiscord, 14 years ago

I got around to testing this with the same flac files on my
Linux box (Fedora Core 3). Using the same data files
(including flac files) I was using on the Mac, I tested
against the 0.7.1 release RPMs. I encountered the same
problem. I tried building from source using the 20050419
snapshot (from http://www.scummvm.org/daily/). The crash
continued to appear.

STDOUT/STDERR:
Looking for monkey
Trying to start game 'Monkey Island 1'
WARNING: Couldn't open drive: !
WARNING: FlacInputStream: could not create an Audiostream
from File track17.fla!WARNING: FlacInputStream: could not
create an Audiostream from File track24.fla!WARNING:
FlacInputStream: could not create an Audiostream from File
track24.fla!scummvm: sound/audiocd.cpp:114: void
AudioCDManager::updateCD(): Assertion `index >= 0' failed.
Aborted

Backtrace from GDB:
#0 AudioCDManager::updateCD (this=0x8528fe8) at
sound/audiocd.cpp:114
#1 0x080656cb in Scumm::Sound::updateCD (this=0x8528968) at
singleton.h:58
#2 0x0805e3cf in Scumm::ScummEngine::waitForTimer
(this=0x85595f0,
msec_delay=34578) at scumm/scumm.cpp:1832
#3 0x0805e335 in Scumm::ScummEngine::go (this=0x85595f0)
at scumm/scumm.cpp:1804
#4 0x08055dae in runGame (detector=@0xbfe94dc0,
system=@0x84fb968)
at base/main.cpp:277
#5 0x080561ca in main (argc=1, argv=0xbfe94eb4) at
base/main.cpp:409
(gdb) p _cd
$1 = {<AudioCDManager::Status> = {playing = true, track =
24, start = 0,
duration = 0, numLoops = -1}, handle = {_val = 0}}

I'll poke around a little more...

comment:10 by SF/chaosdiscord, 14 years ago

Taking a look at the flac files in question, most of them
are clearly hosed. They're mostly full of nulls, but have a
little bit of data that does look like flac meta-data.

track14.fla looks undamaged (it's a 20 second loop that
fades out.) This is the track playing when you load the
save game I provided.

Deleting all of the flac file except 14, then using "touch
track24.fla" to create a bogus track 24 allowed me to
reproduce the problem.

I tried replacing track24.fla with a completely empty file
(courtesy of "dd if=/dev/zero of=track23.fla count=1
bs=8735111"). I left track14 (The track playing when you
load the save game) alone. As far as I can tell, track 14
is functioning correctly (it's a 20 second loop that fades
out toward the end. It sounds silent from seconds about
15-20.) The rest (2-25, excepting 24 and 14) I erased. I
could reproduce the assert this way.

Just in case track 14 was damaged as well, I recorded 20
seconds of silence and encoded that as a flac track. Using
this for track14 also reproduces the assert.

In theory I suspect you can take working MI1 flac files and
"rm track24.fla;touch track24.fla" to reproduce the bug from
my save file. But just in case I'm somehow generating
particularlly screwed flac files, I'm attaching my "silent"
track14.fla and the empty track24.fla. It's just silence
recorded off my machine, so there should be no copyright issues.

comment:11 by SF/chaosdiscord, 14 years ago

Apparently SourceForge has a 256kB limit, so I can't attach
my sample. If anyone wants it, it'll be up here for a while
(probably many weeks before I remember that it's there):
http://alpha.monkeycosm.net/~chaos/mi1_broken_flac_test.tar.gz

comment:12 by cyxx, 14 years ago

Thanks for the "test" files, it made the debugging easier.

I think I found what was wrong and I committed a fix for it.
Still, it would be nice if the bug submitter could (again !)
test if that helps.

comment:13 by cyxx, 14 years ago

Status: newclosed

comment:14 by cyxx, 14 years ago

Resolution: fixed

comment:15 by cyxx, 14 years ago

Closing this. My changes a month ago fixed the problem with
the "test" files.

Note: See TracTickets for help on using tickets.