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.
The M4 engine has it's own globals array and constants,
so it was cleaner to have it remain as Globals, and change
the ScummVM Globals class to Vars to disambiguate it
Paul Gilbert
antoniou79
Eugene Sandulenko
Torbjörn Andersson