Opened 11 years ago

Closed 11 years ago

#6323 closed defect (fixed)

TOLTECS: Crash during peace pipe coughing scene

Reported by: SF/jennibee Owned by: bluegr
Priority: normal Component: Engine: Toltecs
Version: Keywords:
Cc: Game: 3 Skulls of the Toltecs


In the DOS/English version of 3 Skulls of the Toltecs using version 1.7.0git21-g43791c5 on Haiku, ScummVM crashed while playing the scene when coughing after smoking the peace pipe, if you don't use the weak tobacco.

Ticket imported from: #3613032. Ticket imported from: bugs/6323.

Attachments (1)

toltecs.000 (48.0 KB ) - added by SF/jennibee 11 years ago.
Save file from before smoking the peace pipe

Download all attachments as: .zip

Change History (7)

by SF/jennibee, 11 years ago

Attachment: toltecs.000 added

Save file from before smoking the peace pipe

comment:1 by bluegr, 11 years ago

There are two cutscenes in the chief's tent: - one that is shown when using the chief's (regular) tobacco, which makes Fenimore cough and stop, and you need to redo the pipe cutscene (this is what's crashing, according to the OP) - one that is shown when you correctly use the light tobacco, the actual solution to the riddle, and then you can progress

Note that this crash doesn't prevent the game from being completable, as it occurs in a scene that is shown when you don't do the timed event (tobacco swapping) correctly

comment:2 by eriktorbjorn, 11 years ago

It doesn't crash for me in Linux, unless I run it with Valgrind. When I do that, it does crash and I get the following warning/error:

==10853== Warning: silly arg (-2144325632) to malloc() ==10853== Invalid write of size 1 ==10853== at 0x46DFF85: __GI_mempcpy (mempcpy.S:55) ==10853== by 0x46D1CFB: _IO_file_xsgetn (fileops.c:1407) ==10853== by 0x46D4587: _IO_sgetn (genops.c:496) ==10853== by 0x46C75DF: fread (iofread.c:42) ==10853== by 0x90666D7: StdioStream::read(void*, unsigned int) (stdiostream.cpp:68) ==10853== by 0x9155E91: Common::File::read(void*, unsigned int) (file.cpp:141) ==10853== by 0x8C76989: Toltecs::MoviePlayer::fetchAudioChunks() (movie.cpp:221) ==10853== by 0x8C76433: Toltecs::MoviePlayer::playMovie(unsigned int) (movie.cpp:132) ==10853== by 0x8C6B91F: Toltecs::ScriptInterpreter::sfPlayMovie() (script.cpp:1048) ==10853== by 0x8C6BA56: Common::Functor0Mem<void, Toltecs::ScriptInterpreter>::operator()() const (func.h:387) ==10853== by 0x8C6993C: Toltecs::ScriptInterpreter::execScriptFunction(unsigned short) (script.cpp:498) ==10853== by 0x8C68D15: Toltecs::ScriptInterpreter::execOpcode(unsigned char) (script.cpp:273) ==10853== Address 0x0 is not stack'd, malloc'd or (recently) free'd

In fact, it seems to find several chunks of negative size, but the others are of type 0 so they're ignored here. Maybe it's reading beyond the end of the stream, but the sound chunk doesn't seem to be at least. Hmm...

comment:3 by eriktorbjorn, 11 years ago

Something seems a bit odd about fetchAudioChunks(). Even in the intro movie, it appears to be reading past the end of the stream (finding an invalid chunk type just before it does). But if there were invalid chunks, the playMovie() function itself should have errored out, and it didn't.

Actually, I'm puzzled by the end of stream itself. Isn't it all just one big file, so going outside the stream should only happen if the resource is at the end. Unless the bad chunk sizes is what causes it to go outside the stream. That's probably it, but it's far too late at night for me to check.

comment:4 by eriktorbjorn, 11 years ago

I think I see the problem. As the buffered audio is running out, it will call fetchAudioChunks() again and again. When it does, it always initialises chunkCount to _chunkCount, even though it may already have looked at that chunk, and indeed several chunks ahead.

So just like it keeps track of _lastPreferechOfs, it probably needs to keep track of the last chunk count as well.

comment:5 by bluegr, 11 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed

comment:6 by bluegr, 11 years ago

Thanks for all your pointers eriktorbjorn!

The bug has been fixed in both master (commit 98fa064) and branch 1.6 (commit 09d5b1f)

The fix will be available in the next daily version of ScummVM.

Thanks for your report jenibee. Closing as fixed

Note: See TracTickets for help on using tickets.