#996 closed defect (fixed)
FOA: Amiga version always crashes after a few minutes
Reported by: | SF/zaurak | Owned by: | SF/jamieson630 |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Indiana Jones 4 |
Description
Fate of Atlantis; German Amiga version; ScummVM 0.5.0pre-cvs Built on Jul 12 2003 00:40:35
After approx. 2 minutes playing FoA ScummVM always quits reporting:
"Fatal signal: Segmentation Fault (SDL Parachute Deployed)"
Bug is only present with the Amiga version. Bug was already present with ScummVM 0.4.2cvs.
Regards, Jan
Ticket imported from: #770085. Ticket imported from: bugs/996.
Change History (17)
comment:1 by , 21 years ago
Summary: | FoA: Amiga version always crashes after a few minutes → FOA: Amiga version always crashes after a few minutes |
---|
comment:2 by , 21 years ago
comment:3 by , 21 years ago
Never done one before. Could you give me a hint, how to perform one, please?
comment:4 by , 21 years ago
If you are on a unix system, I can (you didn't state what OS you are using, anyway).
comment:6 by , 21 years ago
I can reproduce the problem, the amount of time it takes to crash seems random. Each time it seems to crash in imsue, two back traces:
Program received signal SIGSEGV, Segmentation fault. [Switching to thread 3484.0xb98] 0x0046f980 in IMuseInternal::reallocateMidiChannels (MidiDriver*) ( this=0x369d4f8, midi=0x36f72f8) at scumm/imuse_internal.h:237 237 MidiDriver *getMidiDriver() { return _midi; } (gdb) bt #0 0x0046f980 in IMuseInternal::reallocateMidiChannels (MidiDriver*) ( this=0x369d4f8, midi=0x36f72f8) at scumm/imuse_internal.h:237 #1 0x0046f5ee in Part::clearToTransmit() (this=0x369dd20) at scumm/imuse_internal.h:237 #2 0x0046f610 in Part::sendAll() (this=0x369dd20) at scumm/imuse.cpp:1572 #3 0x0047e477 in Player::sysEx(unsigned char*, unsigned short) ( this=0x369d620, p=0x3176b6d "}", len=20) at scumm/imuse_player.cpp:375 #4 0x004e9696 in MidiParser::onTimer() (this=0x317d938) at sound/midiparser.cpp:191 #5 0x0047f5be in Player::onTimer() (this=0x369d620) at scumm/imuse_player.cpp:974 #6 0x0046ccea in IMuseInternal::sequencer_timers (MidiDriver*) ( this=0x369d4f8, midi=0x36f72f8) at scumm/imuse.cpp:339 #7 0x0046ccb1 in IMuseInternal::on_timer(MidiDriver*) (this=0x369d4f8, midi=0x36f72f8) at scumm/imuse.cpp:330 #8 0x0046fbdc in IMuse::on_timer(MidiDriver*) (this=0x31712f0, midi=0x36f72f8) at scumm/imuse.cpp:1717 #9 0x0046f94b in IMuseInternal::midiTimerCallback(void*) (data=0x36f72f8) at scumm/imuse.cpp:1642 #10 0x004e27ff in MidiDriver_ADLIB::generate_samples (short*, int) ( this=0x36f72f8, data=0x31f7ef8, len=2048) at backends/midi/adlib.cpp:1007 #11 0x004e2768 in MidiDriver_ADLIB::premix_proc(void*, short*, unsigned) ( param=0x36f72f8, buf=0x31f7ef8, len=2048) at backends/midi/adlib.cpp:984 #12 0x004e5990 in SoundMixer::mix(short*, unsigned) (this=0x3128c80, buf=0x31f7ef8, len=2048) at sound/mixer.cpp:284 #13 0x004e5a7e in SoundMixer::onGenerateSamples(void*, unsigned char*, int) ( s=0x3128c80,
samples=0x31f7ef8 "\016uG\025\236\237 )j\002W_", len=8192) at sound/mixer.cpp:302 #14 0x10001e96 in _libwinmm_a_iname () #15 0x10039677 in _libwinmm_a_iname () #16 0x1003982f in _libwinmm_a_iname () #17 0x77e7d33b in _libwinmm_a_iname ()
Program received signal SIGSEGV, Segmentation fault. [Switching to thread 3776.0x264] 0x0046f980 in IMuseInternal::reallocateMidiChannels (MidiDriver*) ( this=0x369d4f8, midi=0x318c188) at scumm/imuse_internal.h:237 237 MidiDriver *getMidiDriver() { return _midi; } (gdb) bt #0 0x0046f980 in IMuseInternal::reallocateMidiChannels (MidiDriver*) ( this=0x369d4f8, midi=0x318c188) at scumm/imuse_internal.h:237 #1 0x0046f5ee in Part::clearToTransmit() (this=0x369dd20) at scumm/imuse_internal.h:237 #2 0x0046f610 in Part::sendAll() (this=0x369dd20) at scumm/imuse.cpp:1572 #3 0x0047e477 in Player::sysEx(unsigned char*, unsigned short) ( this=0x369d620, p=0x317d52d "}", len=20) at scumm/imuse_player.cpp:375 #4 0x004e9696 in MidiParser::onTimer() (this=0x3731a20) at sound/midiparser.cpp:191 #5 0x0047f5be in Player::onTimer() (this=0x369d620) at scumm/imuse_player.cpp:974 #6 0x0046ccea in IMuseInternal::sequencer_timers (MidiDriver*) ( this=0x369d4f8, midi=0x318c188) at scumm/imuse.cpp:339 #7 0x0046ccb1 in IMuseInternal::on_timer(MidiDriver*) (this=0x369d4f8, midi=0x318c188) at scumm/imuse.cpp:330 #8 0x0046fbdc in IMuse::on_timer(MidiDriver*) (this=0x31713a8, midi=0x318c188) at scumm/imuse.cpp:1717 #9 0x0046f94b in IMuseInternal::midiTimerCallback(void*) (data=0x318c188) at scumm/imuse.cpp:1642 #10 0x004e27ff in MidiDriver_ADLIB::generate_samples (short*, int) ( this=0x318c188, data=0x31f9ef8, len=2048) at backends/midi/adlib.cpp:1007 #11 0x004e2768 in MidiDriver_ADLIB::premix_proc(void*, short*, unsigned) ( param=0x318c188, buf=0x31f9ef8, len=2048) at backends/midi/adlib.cpp:984 #12 0x004e5990 in SoundMixer::mix(short*, unsigned) (this=0x3119710, buf=0x31f9ef8, len=2048) at sound/mixer.cpp:284 #13 0x004e5a7e in SoundMixer::onGenerateSamples(void*, unsigned char*, int) ( s=0x3119710, samples=0x31f9ef8 "\003\002A\002v\002S\003\200 \004\005\006\aD\bT\b\a\037\a\005_\004\235 \003\002\001", len=8192) at sound/mixer.cpp:302 #14 0x10001e96 in _libwinmm_a_iname () #15 0x10039677 in _libwinmm_a_iname () #16 0x1003982f in _libwinmm_a_iname () #17 0x77e7d33b in _libwinmm_a_iname ()
comment:7 by , 21 years ago
Owner: | set to |
---|
comment:8 by , 21 years ago
Well, I just ran it, talked my way into Biff letting me in, and it crashes right when it's transitioning to the inside stage scene. However, my crash didn't occur inside iMuse. Here's the MSVC backtrace plus some useful info:
CostumeRenderer::proc3_ami() line 498 + 15 bytes CostumeRenderer::mainRoutine(int -15, int -104) line 276 CostumeRenderer::drawLimb(const CostumeData & {...}, int 2) line 635 + 16 bytes BaseCostumeRenderer::drawCostume(const CostumeData & {...}) line 41 + 21 bytes Actor::drawActorCostume() line 970 + 15 bytes Scumm::processActors() line 875 Scumm::scummLoop(int 6) line 1215 Scumm::mainRun() line 2486 + 12 bytes Scumm::go() line 2584 main(int 2, char * * 0x00c80b30) line 230 + 19 bytes mainCRTStartup() line 206 + 25 bytes KERNEL32! bff8b560() KERNEL32! bff8b412() KERNEL32! bff89dd5() 00c0c0c0()
In proc3_ami(): Line 498: *dst = palette[color]; dst = 0x00c0a31d (CXX0030: Error: expression cannot be evaluated) dst is initialized from v1.destptr: v1.destptr = 0x00c0a30e (CXX0030: Error: expression cannot be evaluated)
Neither pointer seems to point to anything valid.
I will continue to try to get a crash inside iMuse, since that's much more familiar territory and I might have a better idea of what's happening.
comment:9 by , 21 years ago
Another successful crash when entering the theater put me in the middle of the FMOPL code. Considering how widely varied the crash points are, I would recommend a valgrind to identify any OOB memory access in the Amiga-specific functions.
Khalek, I heard you're having trouble with valgrind these days. What's yer status -- are you available to run some valgrind on this?
comment:10 by , 21 years ago
==2450== Invalid write of size 1 ==2450== at 0x806AED8: CostumeRenderer::proc3_ami() (costume.cpp:498) ==2450== by 0x806A64C: CostumeRenderer::mainRoutine(int, int) (costume.cpp:275) ==2450== by 0x806B18A: CostumeRenderer::drawLimb(CostumeData const&, int) (costume.cpp:635) ==2450== by 0x80629A6: BaseCostumeRenderer::drawCostume(CostumeData const&) (base-costume.cpp:41)
seems to be the only relevant output
valgrind runs.. just slower than usual and leak checking causes a segfault as I'm now using the 2.6 kernel....
comment:11 by , 21 years ago
Resolution: | → fixed |
---|---|
Status: | new → pending |
comment:12 by , 21 years ago
I've been having trouble getting FOA Amiga to crash again for me. However, I nailed down the proc3_ami() crash in MI2 (ref Bug #770364) and fixed it. That fix may eliminate FOA crashes here too.
zaurak, I need you to test FOA and see if you can get it to crash. Also, khalek, another test with valgrind would be useful, just in case it still crashes due to OOB writes elsewhere.
comment:13 by , 21 years ago
Status: | pending → new |
---|
comment:14 by , 21 years ago
So far, the crash hasn't occured again. I've played FOA for some time now. I've also used both possibilities to enter the theatre (talking to Biff & moving the chests), but the crash seems to be gone. I will complete the game during the next few days and if the crash doesn't occur again, the bug is fixed, I would say.
comment:15 by , 21 years ago
I have successfully played through FOA (Team Mode) until the end (using ScummVM 0.5.3cvs Aug 12 2003 11:47:15). No crashes have occured again. Bug fixed, I would say. Thanks!
comment:17 by , 21 years ago
Status: | new → closed |
---|
Can you provide a stack trace?