#1454 closed defect (fixed)
COMI: crash during death sequence
| Reported by: | SF/khalek | Owned by: | aquadran |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
There is a reproduceable crash here during the sequence after taking the spiked drink. This doesn't affect Kirben on windows and has been reproduced by endy.
Boot param 620 is the easiest way to test it.
Currently its believed that the following change http://cvs.sourceforge.net/viewcvs.py/scummvm/scummvm/scumm/imuse_digi/dimuse.cpp?r1=1.34&r2=1.35 may have been what introduced the problem. It was not present with a CVS checkout from the 15th January.
Running via gdb and giving a SIGINT (^C) after the crash resulted in the following backtrace:
#0 0x401e2236 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #1 0x401df71d in _L_mutex_lock_21 () from /lib/tls/libpthread.so.0 #2 0x4182000c in ?? () #3 0x00000428 in ?? () #4 0x08363e40 in ?? () #5 0x00000004 in ?? () #6 0x4018eb18 in ?? () from /usr/lib/libSDL-1.2.so.0 #7 0x083824e8 in ?? () #8 0x40185d1c in SDL_mutexP () from /usr/lib/libSDL-1.2.so.0 #9 0x0804d1bb in OSystem_SDL_Common::lock_mutex(Mutex*) (this=0x8356090, mutex=0xfffffffc) at backends/sdl/sdl-common.cpp:1356 #10 0x081a493f in Common::StackLock::lock() (this=0x0) at common/util.cpp:119 #11 0x081a48c8 in StackLock (this=0x0, mutex=0xfffffffc, syst=0x401e5b90) at common/util.cpp:110 #12 0x0806b4c6 in Scumm::IMuseDigital::getCurVoiceLipSyncWidth() (this=0x4) at scumm/imuse_digi/dimuse.cpp:626
I'm running latest CVS, latest and greatesst from Debian sid on x86 Linux. This doesn't affect Kirben on windows and has been reproduced by Endy who is also running Linux.
Ticket imported from: #896525. Ticket imported from: bugs/1454.
Change History (3)
comment:1 by , 21 years ago
comment:3 by , 21 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
An update:
This is apparantly due to the do{..} while; in IMuseDigital::callback getting into an infinite loop.
This loop is due to result (set by _sound->getDataFromRegion) being set to 0 after result &= ~1 and similar.