#4441 closed defect (fixed)
ZAK: Crash when using the yellow crystal (Amiga version)
Reported by: | SF/gplechuck | Owned by: | fingolfin |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Zak McKracken |
Description
Everytime i try to use the yellow crystal the game crashes!! What's wrong?
Ticket imported from: #2824840. Ticket imported from: bugs/4441.
Attachments (2)
Change History (20)
comment:1 by , 15 years ago
Summary: | Zak McKrackeb Amiga-Version Yellow Crystal → Zak McKracken Amiga-Version Yellow Crystal |
---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Summary: | Zak McKracken Amiga-Version Yellow Crystal → Zak McKracken AmigaVersion using Yellow Crystal game crashes |
---|
comment:4 by , 15 years ago
Summary: | Zak McKracken AmigaVersion using Yellow Crystal game crashes → ZAK: Crash when using the yellow crystal (Amiga version) |
---|
comment:5 by , 15 years ago
I have Scummvm 1.0.0.0. Zak McKracken Amiga (Floppy) German Version. After I went to Zaire to the village's doctor to bring him the yellow crystal I try to use it but everywhere i like to go the game crashes without an error message. What is wrong? The error ocurres eyerytime i try to use the yellow crystal.
comment:10 by , 15 years ago
I can reliably reproduce this issue. Here is a backtrace:
#0 0x00007f4167c0bed5 in raise () from /lib/libc.so.6 #1 0x00007f4167c0d3f3 in abort () from /lib/libc.so.6 #2 0x00007f4167c48388 in ?? () from /lib/libc.so.6 #3 0x00007f4167c4d928 in ?? () from /lib/libc.so.6 #4 0x00007f4167c4fa36 in free () from /lib/libc.so.6 #5 0x00000000005b5af1 in ~MemoryReadStream (this=0x18416a0) at ./common/stream.h:562 #6 0x0000000000c33244 in ~RawStream (this=0x18416e0) at sound/decoders/raw.cpp:109 #7 0x0000000000c23280 in ~SubLoopingAudioStream (this=0x1841770) at sound/audiostream.cpp:180 #8 0x000000000059e495 in Scumm::Player_MOD::stopChannel (this=0x17c9d00, id=317) at engines/scumm/player_mod.cpp:114 #9 0x000000000053a018 in Scumm::V2A_Sound_Base<2>::stop (this=0x1841420) at engines/scumm/player_v2a.cpp:90 #10 0x0000000000532891 in Scumm::Player_V2A::updateSound (this=0x17c9c60) at engines/scumm/player_v2a.cpp:1931 #11 0x0000000000532955 in Scumm::Player_V2A::update_proc (param=0x17c9c60) at engines/scumm/player_v2a.cpp:1924 #12 0x000000000059dc59 in Scumm::Player_MOD::do_mix (this=0x17c9d00, data=0x18572d0, len=1241) at engines/scumm/player_mod.cpp:168 #13 0x000000000059ebad in Scumm::Player_MOD::readBuffer (this=0x17c9d00, buffer=0x18572d0, numSamples=2720) at ./engines/scumm/player_mod.h:61 #14 0x0000000000c547ff in Audio::CopyRateConverter<true, false>::flow ( this=0x13c02e0, input=@0x17c9d00, obuf=0x143a040, osamp=2720, vol_l=256, vol_r=256) at sound/rate.cpp:304 #15 0x0000000000c2908a in Audio::Channel::mix (this=0x17c9f80, data=0x143a040, len=1360) at sound/mixer.cpp:548 #16 0x0000000000c2a0cb in Audio::MixerImpl::mixCallback (this=0x1422720, samples=0x143a040 "", len=1360) at sound/mixer.cpp:277 #17 0x000000000040d025 in OSystem_SDL::mixCallback (sys=0x13b22b0, samples=0x143a040 "", len=5440) at backends/platform/sdl/sdl.cpp:702 #18 0x00007f41686dccbd in ?? () from /usr/lib/libSDL-1.2.so.0 #19 0x00007f41686e3ea7 in ?? () from /usr/lib/libSDL-1.2.so.0 #20 0x00007f4168728469 in ?? () from /usr/lib/libSDL-1.2.so.0 #21 0x00007f41677c0fc7 in start_thread () from /lib/libpthread.so.0 #22 0x00007f4167ca959d in clone () from /lib/libc.so.6 #23 0x0000000000000000 in ?? ()
comment:11 by , 15 years ago
Following is a patch that works around this double-free issue. It probably results in leakage, but as I am unaware of scummvm's lifecycle rules, this is the best I could come up with right now.
diff -u scummvm/engines/scumm/player_mod.cpp\~ scummvm/engines/scumm/player_mod.cpp --- scummvm/engines/scumm/player_mod.cpp~ 2010-04-25 22:49:03.000000000 +0200 +++ scummvm/engines/scumm/player_mod.cpp 2010-04-26 21:02:56.000000000 +0200 @@ -97,7 +97,7 @@
Audio::SeekableAudioStream *stream = Audio::makeRawStream((const byte *)data, size, rate, 0); if (loopStart != loopEnd) { - _channels[i].input = new Audio::SubLoopingAudioStream(stream, 0, Audio::Timestamp(0, loopStart, rate), Audio::Timestamp(0, loopEnd, rate)); + _channels[i].input = new Audio::SubLoopingAudioStream(stream, 0, Audio::Timestamp(0, loopStart, rate), Audio::Timestamp(0, loopEnd, rate), DisposeAfterUse::NO); } else { _channels[i].input = stream; }
comment:12 by , 15 years ago
Hi robbe, thanks for your backtrace and analysis. The change you propose would result in memory leaking. But the data you provided was enough (I think) for me to spot the actual problem, and I committed a proposed fix in r48832. Can you please try with that revision and test whether this really fixed the issue?
Thanks again!
comment:13 by , 15 years ago
Owner: | set to |
---|
comment:14 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → pending |
comment:15 by , 14 years ago
This tracker item is pending response by the submitter; we cannot continue processing it before that happens. As a consequence, its status has been set to "Pending". It will automatically revert to "Open" once a new comment is made to this item. If no response is made within 14 days, it will automatically be closed.
Thank you.
comment:16 by , 14 years ago
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
comment:17 by , 14 years ago
Status: | pending → closed |
---|
comment:18 by , 6 years ago
Component: | → Engine: SCUMM |
---|---|
Game: | → Zak McKracken |
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (PLEASE test the latest CVS/Daily build) * Bug details, including instructions on reproducing it * Language of game (English, German, ...) * Version of game (talkie, floppy, ...) * Platform and Compiler (Win32, Linux, MacOS, ...) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!