#6691 SCI: QFG3: Crash when loading Pool of Peace save

[douglas]

using scummvm-1.7.0-win32 in Windows 7 64-bit

When loading a save from the Pool of Peace, sometimes ScummVM will stop responding. I don't know why.

To recreate, load the savegame, then load the savegame again. Sometimes it will crash, and sometimes it won't.

[douglas]

I was wrong about it being specific to the Pool of Peace area, because I encountered the same sort of crash in a different area. savegame attached

[digitall]

Tested with the attached savegames and the latest git master (v1.8.0git) on Linux x86_64,

Can NOT replicate with qfg3.009 loading from launcher (though this does not eliminate the possibility of a unstable bug).

Can reliably replicate with qfg3.008 loading from launcher. This gives:
WARNING: Clone entry without a base class: 2163!
before crashing with a segfault.

Running this under GDB gives the following backtrace from the segfault:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000432cb5 in Common::Array<Sci::reg_t>::operator[] (this=0x28, idx=1)
    at ./common/array.h:163
163         assert(idx < _size);
(gdb) bt
#0  0x0000000000432cb5 in Common::Array<Sci::reg_t>::operator[] (this=0x28, 
    idx=1) at ./common/array.h:163
#1  0x000000000044a312 in Sci::Object::getVariable (this=0x0, var=1)
    at ./engines/sci/engine/object.h:211
#2  0x00000000004f57dd in Sci::Object::locateVarSelector (this=0x12f68e8, 
    segMan=0x118ddd0, slc=57) at engines/sci/engine/object.cpp:97
#3  0x000000000046bf1a in Sci::lookupSelector (segMan=0x118ddd0, 
    obj_location=..., selectorId=57, varp=0x7ffffffb6b70, fptr=0x7ffffffb6b80)
    at engines/sci/engine/selector.cpp:268
#4  0x000000000047807d in Sci::send_selector (s=0x11ec820, send_obj=..., 
    work_obj=..., sp=0x120eaec, framesize=2, argp=0x120eae8)
    at engines/sci/engine/vm.cpp:293
#5  0x000000000047ab72 in Sci::run_vm (s=0x11ec820)
    at engines/sci/engine/vm.cpp:962
#6  0x000000000046be7a in Sci::invokeSelector (s=0x11ec820, object=..., 
    selectorId=57, k_argc=2, k_argp=0x120ead0, argc=0, argv=0x0)
    at engines/sci/engine/selector.cpp:250
#7  0x000000000047dc41 in Sci::GfxAnimate::invoke (this=0x1234e50, 
    list=0x1202800, argc=2, argv=0x120ead0)
    at engines/sci/graphics/animate.cpp:95
#8  0x0000000000480914 in Sci::GfxAnimate::kernelAnimate (this=0x1234e50, 
    listReference=..., cycle=true, argc=2, argv=0x120ead0)
    at engines/sci/graphics/animate.cpp:606
---Type <return> to continue, or q <return> to quit---
#9  0x00000000004430db in Sci::kAnimate (s=0x11ec820, argc=2, argv=0x120ead0)
    at engines/sci/engine/kgraphics.cpp:1134
#10 0x0000000000478610 in Sci::callKernelFunc (s=0x11ec820, kernelCallNr=11, 
    argc=2) at engines/sci/engine/vm.cpp:383
#11 0x000000000047a5a0 in Sci::run_vm (s=0x11ec820)
    at engines/sci/engine/vm.cpp:866
#12 0x0000000000431781 in Sci::SciEngine::runGame (this=0x10e97c0)
    at engines/sci/sci.cpp:718
#13 0x0000000000430105 in Sci::SciEngine::run (this=0x10e97c0)
    at engines/sci/sci.cpp:365

[digitall]

m_kiewitz: Can you replicate?

[Filippos Karapetis]

Seems that a screen object isn't created properly when loading

[Willem Jan Palenstijn]

It looks like this savegame (008) has a clone with baseobj = 0096:0107, but while 0x96 is indeed a script segment (script 33), offset 0x107 does not point at an object in that script. I don't know how such a situation would occur.

[Willem Jan Palenstijn]

Turns out the warning+segfault digitall reports is just a QfG3 version mismatch.

However, I do get the occasional hang when loading this savegame, caused by a deadlock in the audio code somewhere.

[Willem Jan Palenstijn]

(gdb) thread 1
(gdb) bt
[...]
#7  0x00000000006b37a6 in Common::StackLock::StackLock (this=0x7fffe297a9f0,
    mutex=..., mutexName=0x0) at common/mutex.cpp:57
#8  0x000000000066bcfc in Audio::MixerImpl::isSoundHandleActive (
    this=0xe14680, handle=...) at audio/mixer.cpp:452
#9  0x00000000004b7bd1 in Sci::SciMusic::soundPlay (this=0x141a220,
    pSnd=0x14e6620) at engines/sci/sound/music.cpp:470
#10 0x00000000004bba09 in Sci::SoundCommandParser::processPlaySound (
    this=0x141a1e0, obj=..., playBed=false)
    at engines/sci/sound/soundcmd.cpp:208
#11 0x000000000045f43a in Sci::SoundCommandParser::reconstructPlayList (
    this=0x141a1e0) at engines/sci/engine/savegame.cpp:670
#12 0x00000000004604e8 in Sci::gamestate_restore (s=0x1340e10, fh=0x14d66a0)
    at engines/sci/engine/savegame.cpp:963
[...]

(gdb) thread 3
(gdb) bt
#7  0x00000000006b37a6 in Common::StackLock::StackLock (this=0x7fa6b832fc80,
    mutex=..., mutexName=0x0) at common/mutex.cpp:57
#8  0x00000000004b6afe in Sci::SciMusic::miditimerCallback (p=0x141a220)
    at engines/sci/sound/music.cpp:154
#9  0x00000000004c094b in MidiDriver_Emulated::readBuffer (this=0x1412ff0,
    data=0x7fa6b00008e0, numSamples=940) at ./audio/softsynth/emumidi.h:106
#10 0x0000000000698515 in Audio::CopyRateConverter<false, false>::flow (
    this=0x14131a0, input=..., obuf=0xe37990, osamp=940, vol_l=256, vol_r=256)
    at audio/rate.cpp:305
#11 0x000000000066c70a in Audio::Channel::mix (this=0x141c990, data=0xe37990,
    len=940) at audio/mixer.cpp:621
#12 0x000000000066b16d in Audio::MixerImpl::mixCallback (this=0xe14680,
    samples=0xe37990 "", len=940) at audio/mixer.cpp:293