Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001899Dwarf FortressTechnical -- Generalpublic2010-05-16 08:252012-03-17 23:49
Reporterashta_ku 
Assigned ToToady One 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformIntel core 2 6600 w/ 4 GB RAMOSWindows VistaOS VersionUltimate x64
Product Version0.31.03 
Target VersionFixed in Version0.34.01 
Summary0001899: Game locks up for 30 min during seasonal temperature shift
DescriptionSmall (year 1) fort consistently crashes with no apparent cause. Loading the game from last save and taking no action still results in eventual crash of the program if it is unpaused.

So far I have been unable to determine the cause of the crash. Initially I suspected it had to do with the seasonal autosave, but even after disabling that function the crash persisted, so I think that can be ruled out.
Steps To Reproduce1. Load save from http://dffd.wimbli.com/file.php?id=2357 [^]
2. Unpause, then to anything or nothing.
3. Crash.
TagsNo tags attached.
Attached Files

- Relationships
related to 0002063resolvedLogical2u Burning trees near ice lags game 
related to 0004845new Freezing oceanic water causes cave-ins and makes the game freeze too 
has duplicate 0002352resolvedFootkerchief Seasonal ice melting hangs game for a ridiculously long time 
has duplicate 0003079resolvedDwarfu temporary freeze ups and random crashes 
has duplicate 0001462resolvedFootkerchief Ice thawing triggers massive lag 
has duplicate 0004587resolvedFootkerchief Random freeze 
related to 0003750new Occasional infinite loop, apparently caused by pathfinding 
related to 0002296resolvedFootkerchief Crashing during mining 
related to 0002195resolvedLoci Water magically appears 

-  Notes
(0006781)
Logical2u (manager)
2010-05-16 08:33

Before I download the save, could you answer three questions?

1. If you have a military, does completely disbanding the military solve the crash?
2. If you have smelter, does disabling any melting jobs resolve the crash?
3. If you have a hospital zone, does deactivating the hospital zone and stopping your dwarves from receiving medical care (by deconstructing the beds they are resting in) stop the crash?
(0006788)
ashta_ku (reporter)
2010-05-16 08:55

This is a pretty young fortress and doesn't yet have any military or hospital set up.

With regard to the smelter, I checked and verified that no melting jobs are in progress, so I don't believe that is the culprit either I'm afraid.
(0006789)
Logical2u (manager)
2010-05-16 08:58

Alright, I'm downloading the save now and will report back if I can find anything obvious. Thank you for the quick reply!
(0006790)
Logical2u (manager)
2010-05-16 09:28

About when does it crash? My game locked up a little bit after the "Stud with gold" job finished, and it hasn't responded since then, but it hasn't crashed per say. (I have a suspicion that it might resolve itself eventually, much like the giant embark collapse I previously tested).
(0006791)
ashta_ku (reporter)
2010-05-16 09:34

Hmmm, I was asuming that the frozen game was a crash event but maybe you are correct. I will load it up and let it set for an extended period of time to see if it sorts itself out.

But yes, it was becoming non-responsible shortly after the stud with gold message. I will follow up if this resolves the issue.

Thanks!
(0006794)
ashta_ku (reporter)
2010-05-16 10:01

Followup:

It took just short of half an hour, but the game came out of its stall. Thank you for pointing me in the right direction!

Interestingly, the long non-response period seems to have corresponded with the end of a snow storm on the surface.

I guess we can call this one resolved :)
(0006798)
Footkerchief (manager)
2010-05-16 11:44

A thirty-minute lockup doesn't sound normal. This should probably get checked out by Toady.
(0007023)
ashta_ku (reporter)
2010-05-19 14:51

Some additional information after a few more years in the fortress

-the problem on occurs in winter, but does not appear to be always linked with snowstorms.

-the problem always happenes only once a year

-the problem still occurs in 31.04
(0007034)
sloshmonger (reporter)
2010-05-19 19:27
edited on: 2010-05-19 19:28

I've noticed a measurable pause whenever a region temperature reaches the melt threshhold. My current fort is at a three-way regional intersection, and I get three noticeable pauses (22 Obsidian, 4 Granite & 7 Granite) that correspond with ice turning to water on each region.

As I have a large body of water on the last region to melt, I have to make sure at the first pause that my dwarfs are exiting the ice or have high swimming.

This pause is much less noticable if all the ice has been mined out in the large region.

(0007035)
Logical2u (manager)
2010-05-19 19:58

Ah, so this might be a good test - does disabling temperature in the init settings resolve the lockup, ashta_ku? How about for your "pause", sloshmonger?
(0007114)
ashta_ku (reporter)
2010-05-20 19:50

Turning temperature off prevented the pause from occuring at my fort.
(0010831)
Lord_Dakstar (reporter)
2010-07-22 10:32
edited on: 2010-07-22 10:51

The pause is occuring due to the pathing updates due to the freeze/melt of water. Any map with significant amount of water that transitions has the same issue. The game isn't crashed, it's just busy recalculating its path maps due to EACH UNCOVERED WATER TILE CHANGING due to to its FREEZING. What is needed to fix this problem is a special step whenever the temperature crosses water's melt/frozen threshold: temporarily turn off pathing updates, change all water tiles to frozen (and mark them if needed so the code knows to recalculate its pathing map), and when no more water tiles are left to transition to frozen, then conduct the pathing map update, return to normal processing. It only needs to be done ONCE a season--- when outside water freezes. This would result in cold maps that have yearly freezing events to only having a small pause for the change, rather than 10 minute to 60 minute pauses while it calculates the change.

Funnily enough, the reverse of the ice obstacles transitioning (MELTING) does not have this problem to such a notable degree (at least on the freezing maps I've played).

The workaround you as a player can do (while leaving temperature option on) is to cover up your significant water sources on the map or drain it. Either works, as covered water doesn't freeze, and if the water isn't there, it cannot freeze. If you don't want to deal with the long pauses when the water freezes while you are covering it up on your map, temporarily turn off temperature, build your water covers, then go turn back on the temperature options. That should fix your problem on the map and allow you to enjoy the temperature option for the rest of your playing.

Note: I think it is the freezing side of the cycle that causes the super long calculations. I might have that the wrong way around, as my last freezing map was a couple of games/fortresses ago. But the fix is still the same. It is the unnecessary calculating the machine is doing tile by tile due to the change in open/obstacle status when we know that during the seasonal FREEZING/MELT transition of the water on the map, we will most likely have many water tiles that change status, rather then this being a single change like the door being locked or unlocked, or a small number of tiles changing (such as a bridge changing states). So having the game suspend the path recalculating until all water tiles have been transitioned would skip all that unnecessary calculatons that just waste the players time--- we only need to recalculate the final map with all the water transitioned in this particular case.

(0021456)
Toady One (administrator)
2012-03-14 03:56

My understanding is that I fixed the main cause of ice-lag for 34.01.

- Issue History
Date Modified Username Field Change
2010-05-16 08:25 ashta_ku New Issue
2010-05-16 08:33 Logical2u Note Added: 0006781
2010-05-16 08:34 Logical2u Issue Monitored: Logical2u
2010-05-16 08:48 Logical2u Tag Attached: AWAITING UPDATE
2010-05-16 08:48 Logical2u Issue End Monitor: Logical2u
2010-05-16 08:55 ashta_ku Note Added: 0006788
2010-05-16 08:58 Logical2u Note Added: 0006789
2010-05-16 08:58 Logical2u Tag Detached: AWAITING UPDATE
2010-05-16 09:28 Logical2u Note Added: 0006790
2010-05-16 09:34 ashta_ku Note Added: 0006791
2010-05-16 10:01 ashta_ku Note Added: 0006794
2010-05-16 11:44 Footkerchief Note Added: 0006798
2010-05-16 11:45 Footkerchief Summary Reproducible crash - cause unclear => Game becomes unresponsive for 30 min, possibly related to end of snow storm
2010-05-19 14:51 ashta_ku Note Added: 0007023
2010-05-19 19:27 sloshmonger Note Added: 0007034
2010-05-19 19:28 sloshmonger Note Edited: 0007034 View Revisions
2010-05-19 19:58 Logical2u Note Added: 0007035
2010-05-20 19:50 ashta_ku Note Added: 0007114
2010-06-16 05:46 Logical2u Relationship added parent of 0002352
2010-06-29 07:38 Footkerchief Category Technical => Technical -- General
2010-06-30 17:21 Khym Chanur Issue Monitored: Khym Chanur
2010-07-22 09:43 Jinalealia Issue Monitored: Jinalealia
2010-07-22 10:32 Lord_Dakstar Note Added: 0010831
2010-07-22 10:33 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:34 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:38 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:44 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:46 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:48 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 10:51 Lord_Dakstar Note Edited: 0010831 View Revisions
2010-07-22 11:32 Footkerchief Summary Game becomes unresponsive for 30 min, possibly related to end of snow storm => Game locks up for 30 min during seasonal temperature shift
2010-08-20 23:35 Dwarfu Relationship added has duplicate 0003079
2010-11-28 12:48 Footkerchief Relationship added related to 0003750
2010-12-23 10:14 Footkerchief Relationship added related to 0002063
2011-02-06 10:32 Dwarfu Relationship added related to 0002296
2011-03-30 13:37 Footkerchief Relationship added has duplicate 0001462
2011-03-30 13:39 Footkerchief Relationship added related to 0002195
2011-08-20 06:06 Logical2u Relationship added parent of 0004845
2012-02-13 12:01 Footkerchief Tag Attached: Fixed in 0.31.26?
2012-02-14 05:12 Footkerchief Tag Renamed Fixed in 0.31.26? => Fixed in 0.34.01?
2012-02-25 13:00 Footkerchief Relationship replaced has duplicate 0002352
2012-02-25 13:00 Footkerchief Issue Monitored: KTaipan
2012-02-25 13:00 Footkerchief Issue Monitored: plynxis
2012-02-25 13:00 Footkerchief Issue Monitored: btbonval
2012-02-25 13:00 Footkerchief Issue Monitored: Kogut
2012-02-26 11:49 Buglist Issue Monitored: Buglist
2012-03-14 03:55 Toady One Relationship replaced related to 0004845
2012-03-14 03:56 Toady One Note Added: 0021456
2012-03-14 03:56 Toady One Status new => resolved
2012-03-14 03:56 Toady One Fixed in Version => 0.34.01
2012-03-14 03:56 Toady One Resolution open => fixed
2012-03-14 03:56 Toady One Assigned To => Toady One
2012-03-14 03:56 Toady One Tag Detached: Fixed in 0.34.01?
2012-03-15 15:35 Buglist Issue End Monitor: Buglist
2012-03-17 23:49 Kogut Issue End Monitor: Kogut
2014-01-20 18:57 Footkerchief Relationship added has duplicate 0004587


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker