#3350 closed defect (fixed)
COMI: Crash in SVN but not in 0.X.0
Reported by: | SF/thunderpeel2001 | Owned by: | fingolfin |
---|---|---|---|
Priority: | high | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Monkey Island 3 |
Description
Using ScummVM SVN my COMI has just crashed. When Guybrush jumps out into the RUM ROGERS diorama, eventually LeChucks appears and forces him back onto the ride. But it crashes as Guybrush gets back into the cart.
Tested on ScummVM SVN July28th on Vista.
Save attached.
Ticket imported from: #1763227. Ticket imported from: bugs/3350.
Attachments (1)
Change History (17)
by , 17 years ago
comment:2 by , 17 years ago
No sorry, ScummVM just hangs silently. It doesn't crash (ie. disappear) it hangs and I have to force quit it. It happens in the save, just make sure that Guybrush jumps out at the next diorama (with Rum Rogers in it) and then wait until LeChuck shows up.
comment:3 by , 17 years ago
This bug seems very similar to #1527274 "COMI: Freeze in Chapter VI, rollercoaster"
comment:5 by , 17 years ago
It seems to lockup in engines/scumm/imuse_digi/dimuse_track.cpp:95, in IMuseDigital::startSound() while waiting for the requested track to become free. An excerpt from the backtrace:
#13 0x00118348 in Scumm::ScummEngine::parseEvents (this=0x9c05000) at engines/scumm/input.cpp:62 #14 0x00050f84 in Scumm::IMuseDigital::startSound (this=0x605ba00, soundId=1512, soundName=0x852a48 "1512-RUM.IMX", soundType=2, volGroupId=3, input=0x0, hookId=0, volume=127, priority=126) at engines/scumm/imuse_digi/dimuse_track.cpp:95 #15 0x0004f43c in Scumm::IMuseDigital::startMusic (this=0x605ba00, soundName=0x852a48 "1512-RUM.IMX", soundId=1512, hookId=0, volume=127) at engines/scumm/imuse_digi/dimuse_script.cpp:230 #16 0x00177a48 in Scumm::IMuseDigital::playComiMusic (this=0x605ba00, songName=0x852a30 "stateRum", table=0x852a2c, atribPos=87, sequence=true) at engines/scumm/imuse_digi/dimuse_music.cpp:328 #17 0x00177d64 in Scumm::IMuseDigital::setComiMusicSequence (this=0x605ba00, seqId=2000) at engines/scumm/imuse_digi/dimuse_music.cpp:259 #18 0x0004fab0 in Scumm::IMuseDigital::parseScriptCmds (this=0x605ba00, cmd=4097, b=0, c=0, d=0, e=0, f=0, g=0, h=0) at engines/scumm/imuse_digi/dimuse_script.cpp:131 #19 0x0004fd64 in Scumm::IMuseDigital::refreshScripts (this=0x605ba00) at engines/scumm/imuse_digi/dimuse_script.cpp:209 #20 0x00020028 in Scumm::ScummEngine_v7::scummLoop_handleSound (this=0x9c05000) at engines/scumm/scumm.cpp:2140 #21 0x0002a964 in Scumm::ScummEngine::scummLoop (this=0x9c05000, delta=5) at engines/scumm/scumm.cpp:1943 #22 0x0001f650 in Scumm::ScummEngine::go (this=0x9c05000) at engines/scumm/scumm.cpp:1748
comment:6 by , 17 years ago
Owner: | set to |
---|
comment:7 by , 17 years ago
Priority: | normal → high |
---|
comment:8 by , 17 years ago
Does this still happen? I wasn't able to reproduce it, neither with the original voice/music files nor with compressed ones. I do get that annoying "IMuseDigital::cloneToFadeOutTrack: Not free fade track!" a couple of times, though.
comment:10 by , 17 years ago
Hmm? But what should have fixed it since three weeks ago? I am not aware of any changes to the responsible code...
comment:11 by , 17 years ago
Maybe it's random? I made three attempts with an older version (revision 29000), and it hung once.
comment:12 by , 17 years ago
Well I don't have time to try to reproduce it tonight, but when I last tried it, I at first also thought that it was random. But then I noticed that if I followed the instructions here *precisely*, it was rather reliable. That is: jump in, jump out, wait -- no unnecessary actions in between. Anyway, I don't believe it is fixed.
comment:13 by , 17 years ago
> That is: jump in, jump out, wait -- no unnecessary actions in between.
Jump in? I thought it was just jumping out at the Rum Rogers diorama and then keep still, waiting for it to happen?
comment:14 by , 17 years ago
I've tried this part before patch #1839861, and as mentioned, the crashes were a bit random. I've tried it again with patch #1839861, which seems to have fixed other bugs too. I couldn't reproduce it, but as mentioned it's a bit random (unlike the other related bugs). I believe that patch #1839861 fixed the real issue for those crashes, so this could be closed...
comment:15 by , 17 years ago
I am closing this as despite several dozen attempts, I wasn't able to reproduce this anymore, while before the patch, I could frequently reproduce the lockup. At the very least, the frequency of the issue was dramatically reduced. But I think that we did indeed address the core issues here: Trying to clone&fade tracks which were to be removed, postponing track deletion unnecessarily, and a race condition in startSound().
comment:16 by , 17 years ago
Owner: | changed from | to
---|---|
Resolution: | → fixed |
Status: | new → closed |
Rum Rogers crash