#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 |
| Version: | 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)
Change History (16)
by , 19 years ago
| Attachment: | monkey.s12 added |
|---|
comment:1 by , 19 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 , 19 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 , 19 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:5 by , 19 years ago
| Owner: | set to |
|---|---|
| Summary: | Jungle scene with monkey (you give banana to) crashes → MI: Jungle scene with monkey (you give banana to) crashes |
comment:6 by , 19 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 , 19 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:9 by , 19 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 , 19 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 , 19 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 , 19 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 , 19 years ago
| Status: | new → closed |
|---|
comment:14 by , 19 years ago
| Resolution: | → fixed |
|---|
comment:15 by , 19 years ago
Closing this. My changes a month ago fixed the problem with the "test" files.
Save game near crash point