In some cases the engine may access unallocate space or do a double free_mem on an "machine" object
This can happen when a script "machine"'s step triggers a callback that can result to killing the machine itself (via terminateMachineAndNull()) and free its allocated space via a different pointer, but the code in the machine's step continues to try and access the machine's now unallocated space with its original pointer.
This can be observed by running valgrind with scummvm on Linux. Otherwise crashes may occur in Linux and mingw-w64 release mode builds.
An example case is when Wilbur runs on the hamster wheel on the bottom level of the gerbil case (room602).
The proposed solution here is a workaround, based on valgrind's output, and probably does a poor job of cleaning "machine" memory that's no longer used.
More knowledge on the engine's workings is required for a proper and more efficient fix.
The workaround skips full deallocation of a machine object (in the shutdownMachine()), until the ws_KillMachines() is called. The machID field value of 0xdeaddead is used to skip the machine (which remains in the chain). A more efficient fix could do a full deallocation of a machine object earlier (and remove it from the chain like the previous code did), thus avoiding cluttering of the machine's chain.
I don't have a BE system to test this out properly, but in
theory it should be cleaner to do any byte swapping for
loaded resources at load time rather than everywhere the
resource is accessed.
In a few places, such as script execution, it won't be
feasible to track down which bytes are the opcodes and
switch them beforehand. But for others, such as cels,
it should be possible to similar to what I've done here
to ensure the data can be accessed natively afterwards.
D G Turner
Paul Gilbert
antoniou79
Eugene Sandulenko
Torbjörn Andersson