0008732: Jobs randomly "forgotten" - Dwarf Fortress Bug Tracker

Notes
(0031910) Footkerchief (manager) 2015-01-12 11:06	Does it reproduce in 0.40.24 without the use of third-party utilities?

(0031911) PatrikLundell (reporter) 2015-01-12 12:47	Taking the same game, but somewhat later than the uploaded save and continuing with 0.40.24 (freshly downloaded, no 3:rd party utilities) the non allocated chest building order was never performed, despite the No Job number reaching above 20, and at least half, and probably more, of those ought to have Furniture Hauling activated. Likewise, the buggered digging designations were not performed, even when the miners ran out of jobs. A couple of attempts to recreate the missed digging square order failed, i.e. everything was dug out successfully (although in a highly inefficient fashion, as the dwarves ran back and forth between two z-levels to dig out one or two tiles before heading to the other level to repeat that. I believe that's a known issue). I roughly tried to repeat the obsidian mining case, where I'd ordered digging of two or three levels at the same time. However, the mining issue is rare, I have had something like 6 failed squares out of thousands of dug tiles. Since I let things run to let dwarves become idle, I haven't tried to repeat the failure to get to jobs for new jobs. My conclusion of the above is that something in at least 0.40.23 is capable of setting jobs in a state that's inconsistent internally (if DF was multi threaded, I'd suspect concurrent access of unprotected data), and this state carries over to the newer version. Failure to repeat generation of the problem thus far in 0.40.24 doesn't mean much, as the sample size is too small to be conclusive. Since similar symptoms occur for digging, hauling, building, and workshops, I'd guess the buggered state is something that's common to all jobs. Wild speculations below, of little actual value: A random possible cause might be a job being allocated to one dwarf, and thus removed from the list of available jobs, but then dropped for whatever reason (one of my two miners might have been in the way of the other), and only being returned to one of two queues it ought to be included in. I guess jobs in inaccessible sites remain in the "to do" queue that gets displayed in the jobs list, but not in the queue of jobs that can be allocated, for instance (maybe similar to the way you can allocate the building of a wall from a staircase, but if the wall segment directly in front of the staircase is built first, the one to the side appears in the jobs list, but will never get allocated, and never get cancelled automatically, but in this case the job doesn't get returned to the available list when the transient blocking reason disappears).

(0031912) Footkerchief (manager) 2015-01-12 13:11	Need a save demonstrating the problem in 0.40.24 without the use of utilities.

Issue History
Date Modified	Username	Field	Change
2015-01-12 09:42	PatrikLundell	New Issue
2015-01-12 11:06	Footkerchief	Note Added: 0031910
2015-01-12 11:06	Footkerchief	Assigned To	=> Footkerchief
2015-01-12 11:06	Footkerchief	Status	new => needs feedback
2015-01-12 12:47	PatrikLundell	Note Added: 0031911
2015-01-12 12:47	PatrikLundell	Status	needs feedback => assigned
2015-01-12 13:11	Footkerchief	Note Added: 0031912
2015-01-12 13:11	Footkerchief	Status	assigned => needs feedback
2015-03-29 08:09	Footkerchief	Status	needs feedback => resolved
2015-03-29 08:09	Footkerchief	Resolution	open => unable to reproduce

Relationships