#439 closed defect
DOTT: random crashes in the 2. cutscene
| Reported by: | SF/trinity78 | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Day of the Tentacle |
Description
Using the latest Daily Build, Win2k and german DOTT talkie. I get random crashes it the second cutscene. this is the cutscene where they go back in time with the vortex in the background and then freds diamond breaks. this crashes a very random, they seem to occur at different places in the cutscene, sometimes when the black cat appears, sometimes when the diamond breaks and sometimes at the end of the cutscene.
this didn't happen with scummvm 0.20 or any other older daily builds. i can skip the cutscene to avoid these crashes.
Ticket imported from: #601926. Ticket imported from: bugs/439.
Attachments (2)
Change History (14)
comment:1 by , 22 years ago
| Priority: | normal → high |
|---|
comment:2 by , 22 years ago
by , 22 years ago
by , 22 years ago
comment:3 by , 22 years ago
i've uploaded two screenshot where the crashes take place, the crashes always happen at one of these positons or with some luck the cutscene plays fine without crashes.
as i said very random.
comment:4 by , 22 years ago
using a msvc++ 6.0a compiled build (also happens with downloadable daily snapshot) from 13 september 2002 and checking it with numegas boundchecker provided following result, maybe its usefull to someone.
the crash dump:
CREATE_THREAD EXCEPTION(2nd Chance) Exception: Access Violation code: C0000005 addr:00446989 -00046989 (00400000) invalid read from 000000A8 EAX:00000000 EBX:004462D0 ECX:00000040 EDX:018B9508 ESI:01EDFCC8 EDI:01EDFCB8 ESP:01EDFC64 EBP:01EDFCB8 EIP:00446989 EFLAGS:00000246 CS:001B DS:0023 ES:0023 SS:0023 FS:0038 GS:0000 Stack dump 01EDFD18:01EDFCC8:004462D0:CCCCCCCC Call stack !00046989 !000436A8 !000465FE !0003FCD2 !00042294 !0003D32E !0003D287 !00046360 Exception: Access Violation EXIT_THREAD
comment:5 by , 22 years ago
some further infos,
i did at least 10-15 test-runs with the parameter "-enull" (no music) and it DIDN'T crash once. so it is possible that the crashes are either related to "music in general" or in particular to "-ewindows" (windows midi).
comment:6 by , 22 years ago
Trinity, any new word on whether Patch 610257 corrects the problems you were having with this cutscene?
comment:8 by , 22 years ago
Logged In: NO
void IMuseGM::part_changed(Part *part, byte what) { MidiChannelGM *mc;
/* Mark for re-schedule if program changed when in pre-state */ if (what & pcProgram && part->_percussion) { part->_percussion = false; update_pris(); }
if (!(mc = part->_mc->gm())) return;
if (part->_player == NULL) { /* No player, so dump phantom channel */ part->_mc = NULL; mc->_part = NULL; memset(mc->_actives, 0, sizeof(mc- >_actives)); return; }
if (what & pcMod) midiPitchBend(mc->_chan,
clamp(part- >_pitchbend + part->_detune_eff +
(part->_transpose_eff << 7), -2048, 2047));
if (what & pcVolume) midiVolume(mc->_chan, part->_vol_eff);
if (what & pcPedal) midiPedal(mc->_chan, part->_pedal);
if (what & pcModwheel) midiModWheel(mc->_chan, part- >_modwheel);
if (what & pcPan) midiPan(mc->_chan, part->_pan_eff);
if (what & pcEffectLevel) midiEffectLevel(mc->_chan, part- >_effect_level);
if (what & pcProgram) { if (part->_bank) { midiControl0(mc->_chan, part->_bank); midiProgram(mc->_chan, part->_program, part->_player->_mt32emulate); midiControl0(mc->_chan, 0); } else { midiProgram(mc->_chan, part->_program, part->_player->_mt32emulate); // <------- the crashes ocurr here } }
if (what & pcChorus) midiChorus(mc->_chan, part- >_effect_level); }
comment:9 by , 22 years ago
Ref Patch #615737. This provides a quick-and-dirty solution to the problem, although the broader threading issues still stand.
comment:10 by , 22 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:11 by , 22 years ago
Well, I'm going to close this. Basically, this bug is an underlying problem, as addressed in the patch, with a form of race condition. But the circumstances required to create the problem are fairly rare.
To be addressed in the patch report.
comment:12 by , 22 years ago
Logged In: NO
hmm, I think this bug is more serious than it looks and the conditions are not that rare as you think. if you use win2k/xp (its related to windows midi) it crashes approximately 3 out 10 times. I would call this a rare condition. Also it indicates as you said, a more general problem with windows midi/ imuse. I hope "midi-guru" jamieson630 finds a fix for this.
i dont know if this has anything to do with it, but at the console i get a lot of these "Expired resources, mem xxxxxx - > xxxxxx" messages.