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

Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0008732	Dwarf Fortress	Dwarf Mode -- Jobs, General	public	2015-01-12 09:42	2015-03-29 08:09

Reporter	PatrikLundell
Assigned To	Footkerchief
Priority	normal	Severity	minor	Reproducibility	random
Status	resolved	Resolution	unable to reproduce
Platform	PC	OS	Windows	OS Version	8.1
Product Version	0.40.23
Target Version		Fixed in Version

Summary	0008732: Jobs randomly "forgotten"
Description	For some reason, some jobs just never gets scheduled, even though eligible dwarves are displaying "no job" for quite some time. If the job is cancelled and then recreated (while the game is still paused) the jobs are then performed. Examples: - Non repeat construction order for list of armor, with metal available. The armorsmith does nothing. Pause, remove the jobs, and recreate identical jobs in the same order. The armorsmith jumps straight to it. - Digging orders: Miners are ordered to dig out an area. They sometimes skip some tiles that remain marked, but still go to "no job" status. The tiles are definitely reachable (e.g. the central tile of a 3*3 room beside a corridor with identical rooms). - Construction orders: Some wall segments never gets built, with workers going to "no job" instead of taking it up. Removing the job and recreating it will get them going. - Item hauling/construction: An armor stand that's been specified for a year or so (still satisfying the noble's demand, so I didn't care). Removing and recreating the order gets it executed (and there was only a single possible armor stand to perform the order with). I still have a chest that I think was ordered to be placed at the same time that hasn't been build. Item dumping of worn clothing on a building site that hasn't been done for over half a year. 8 out of 9 items removed, but the last one never gets picked up, despite the dump order backlog being cleared and workers are available. Eventually I got it removed by removing the dumping task and recreating it.
Steps To Reproduce
Additional Information	Save uploaded at http://dffd.wimbli.com/file.php?id=10432 [^] When loaded, the save displays a corridor with rooms, one of which has an ordered chest construction that never is performed. Go up 14/15 z-levels to find two obsidian mining rooms with 1/2 tiles that never got mined out. I think those rooms were dug out about half a year earlier. Using PyLNP with Dwarf Therapist, Announcement Filter, and DFHack Workflows, Performance Tweaks, and Pure Bugfixes. This report contains the same issues as the second half of 0008731, but in more detail and with an uploaded save. 0008731 was dismissed because the first half has a connection to DFHack. I believe the issues listed here are unrelated to DFHack, and resolving these will probably also remove the problems in that report, but may of course be wrong. If this report is dismissed as well, I will not pursue the issue further.
Tags	No tags attached.
Relationships
Attached Files

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

Notes

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).