Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Grimwulf]

I'm running a 5-year-old fort with a population of 138 dwarves. Everything was fine, technically speaking. No crashes, no lags, no fps drops. The world is a young 65x65 region, and the embark site is 3x3. Although my laptop is pretty darn old, 4 GB RAM only, once again - I have never experienced any lags or FPS drops.

Then the game started simply crashing on me. Consistently. I start the game, 5-10 mins in, and it CTD's with no error message. No matter what I do. Much research later, I tried all the usual measures, like:
- turning TBWT on/off
- turning DFHack on/off
- disabling labors
- Armok knows what else, can't even remember (got myself pretty drunk trying to debug this thing)

I also made sure the crash isn't something the community knows about. It's not corrupted equipment (my military never ventured outside), it's not about refusing to give away artifacts (nobody wants them), and it's not TWBT or tileset-related. I'm using LNP+Vettlingr, v. 47.04. How do I know it's not related?

Because I found a way to fix crashing the game. All I have to do is NOT to do anything. I tried to leave the game alone. It ran through the whole Season, dwarves mostly loitering and following manager's repeating orders I had scripted previously. The game runs fine.

But when I pause the game and start doing anything, - and I mean anything, - it crashes. Sometimes it crashes when I designate mining a new tunnel. Sometimes it crashes when I check my kitchen stocks. Or sroll down dwarven thoughts. In other words, it crashes upon pressing a key/making any kind of input - not the FIRST input upon loading the game, but maybe 30-50 keypresses after starting the game, if that makes any sense.

Any ideas on what the culprit could be would be much appreciated.

[PatrikLundell]

At a guess it's either related to timing somewhere or an RNG number. Doing things may cycle the RNG to get a "bad" one that provokes the crash when coupled with whatever operation causing it.

However, you'd need to write a bug report and upload your save to DFFD for anyone to be able to investigate it.

The zero size critter bug only crashes the game when the critter is subjected to a calculation where its size is used in a division (division by zero is bad), and it's entirely possible for such critters to be spawned, move around, and leave without the game needing to perform such operations (as an example of a known bug where circumstances decide whether it will cause a crash or not).

[Grimwulf]

Thanks. I had no idea the game is calculating something even when I'm just browsing menus and doing something on pause. 

Anyway, the issue is resolved. Somehow using the NTCore 4Gb patch https://ntcore.com/?page_id=371 fixed the crashing for me. Still beats me why the game was running perfectly without user input if it really was a memory issue.

[lethosor]

That's strange - the tool you linked only works on 32-bit executables, and if you're using a 0.47.04 pack, it's almost certainly a 64-bit executable, which wouldn't have been memory-limited (in a significant way) to begin with and shouldn't be affected by that patch. I'd be surprised if that fixes it permanently. If it does actually do something to 64-bit executables as well, I remember similar tools changing the behavior of nondeterministic crashes in the past (when DF was only 32-bit), so maybe it could be affecting the timing or likelihood of a specific memory corruption issue here too.

Just in case it comes up again, you've also been able to reproduce this with DFHack completely disabled, right? (No console, no "DFHack" indicator on the title screen, etc.) Does it just happen with this save?
If that's the case, it would definitely be worth coming up with a save where the issue can be reproduced in a shorter time frame / with fewer steps, if possible, and reporting this on Mantis.

[Grimwulf]

Aye, the tool didn't fix it permanently. The game started crashing again after an in-game year or so.

Running DFHack's "cleanconst" command seemed to both fix the crashing and improve FPS a great bit. I had almost 20 000 stone blocks listed in my Stocks menu before running the command. I played the fort for another 10 years or so and then retired, no more crashing problems.

[lethosor]

Interesting - at this point, I might begin to suspect a physical memory issue, which programs like DF could be more likely to trigger as they use more memory. "cleanconst" does result in DF using less memory, but would be unlikely to directly solve a crash unless construction items themselves are corrupted (which I would expect to also trigger a crash when saving a game, possibly even loading it, and maybe more frequently than what you're seeing when the game is running).

I'm not trying to send you on a search for an issue that doesn't exist, of course - I'm glad you were able to fix it!