[2.0.73] Crash "entity->isSetup() was not true"

[rosilisk]

I'm regularly experiencing a game crash in my Space Exploration modded world. I'm at Bio 2 and Energy 2 with a 100x multiplier, so the world is relatively large and things get sluggish and sometimes fail. But I've seen this error a few times now. The relevant portion of the crash log seems to be:

Code: Select all

Stack trace logging done
4126.215 Error ConsistencyScraper.cpp:67: entity->isSetup() was not true
4126.215 Error CrashHandler.cpp:643: Received 22
Logger::writeStacktrace skipped.
4126.216 Info ConsistencyScraper.cpp:51: random check: surface Rinoto, chunk [23, 2043], entity [name=huge-rock-volcanic, type=simple-entity(SimpleEntity), position={760.563, 65387.813}, direction=<no>, force=<no>, surface=Rinoto, setup=false, owned-by-ghost=false, to-be-deconstructed=false, to-be-upgraded=false, simulation=true]
4126.216 Error CrashHandler.cpp:190: Map tick at moment of crash: 246377898
4126.324 Info CrashHandler.cpp:318: Executable CRC: 983102098

It looks like something is wrong with a huge volcanic rock on Rinoto, a planet I developed relatively recently (20 hours ago?). I've had several similar crashes referencing the same rock at the same location, so it seems like something is wrong there in particular. The world size is large (650 MB) and some global alarms are currently enabled, so turn down/off the sound. There are no other major mods and I'm happy to test or provide other logfiles. The crash occurs regularly (every few hours) but not predictably; I'm not sure why. It often occurs during gameplay but I've seen other crashes during saving too.

Links:

Main crash logfile: https://drive.google.com/file/d/1-ND914 ... sp=sharing
Autosave before main crash: https://drive.google.com/file/d/1_hiQ_J ... sp=sharing
Another crash log from same rock: https://drive.google.com/file/d/1jTDQMm ... sp=sharing
Another crash log from different rock: https://drive.google.com/file/d/1bL3SAC ... sp=sharing

Thanks! I could try finding and deconstructing the rock in question but I wanted to provide some info to potentially fix the issue. I first posted this on Erandel's discord but was directed to post here as it is a hard crash.

[rosilisk]

I got some good feedback from the SE discord - based on the rock's position (65387.813, close to 2^16) it could be a bit flip or other memory corruption. I saved the game with the

Code: Select all

enable-corrupt-position-recovery

setting enabled and we'll see if that prevents the crash long-term. I'm curious what people here say too, though.
In particular, is there any way to run a consistency check procedurally, and how can I fix any issues if they pop up? I am comfortable using the editor and commands if necessary - for example loop through all rocks and look for far out positions.

[Rseding91]

I saved the game with the

Code: Select all

enable-corrupt-position-recovery

setting enabled and we'll see if that prevents the crash long-term. I'm curious what people here say too, though.

That value only applies when *loading* save files. It does nothing when saving.

... is there any way to run a consistency check procedurally?

Yes:

Code: Select all

/c game.check_consistency()

... and how can I fix any issues if they pop up?

You can't. Errors found during consistency checks indicate total failure or memory failure corrupting things. They are *never* meant to happen so typically the fix is fixing the engine bug that caused them (very very rare these days), or reverting to an older save and fixing/replacing the faulting hardware.

[rosilisk]

Thanks a lot, this helps a lot. The game state indeed fails a consistency check, and I had seen a couple RAM issues so perhaps that's the source. Good to know about the position recovery. I also tried a command to delete the one rock in question but the game failed consistency for other reasons.

Thankfully the problem occurred when I was running a longer stress test on the factory, so I have an earlier save I planned to revert to anyways. The earlier save passes the consistency check, too!

Thanks your help, I agree this issue should be closed due to a hardware failure.