buildingplan: planning mode builds fail sometimes - flags bitfield not initialized

[ab9rf]

I made a burial room with space for 25 coffins. Placed 25 coffins (with 25 available in inventory) in planning mode. Promptly after unpause, seven of the planned coffins disappeared from the map, but the spaces where they were planned to be built are shown as "occupied". Seven more were cancelled, with cancellation notices; the spaces they were planned to be built are clear. Two were built. The remaining are pending building at this time.

I cannot discern any pattern to which ones were cancelled/ghosted/built/not built. I don't see any way to recover the "ghosted" squares.

Additional info: after the weird behavior, the following errors get spammed to the DFHack console on a recurring basis:

C:\Users\Kelly\df_43_05_win\hack\lua\utils.lua:309: table index is nil
stack traceback:
        C:\Users\Kelly\df_43_05_win\hack\lua\utils.lua:309: in function 'utils.parse_bitfield_int'
        C:\Users\Kelly\df_43_05_win\hack\lua\plugins\workflow.lua:116: in upvalue 'guess_job_material'
        C:\Users\Kelly\df_43_05_win\hack\lua\plugins\workflow.lua:228: in upvalue 'enum_job_outputs'
        C:\Users\Kelly\df_43_05_win\hack\lua\plugins\workflow.lua:241: in function 'plugins.workflow.doEnumJobOutputs'

[lethosor]

Is workflow active? Also, have you seen this in 0.43.03? If it's just in 0.43.05, is it in both builds or just the 64-bit build?

[ab9rf]

I think workflow is enabled but not actually being used for anything. I haven't tested in 32-bit. I did not have this problem in 0.43.03.

[lethosor]

Confirmed in both builds of 0.43.05, and confirmed to work properly in 0.43.03.

[lethosor]

building.flags doesn't appear to be getting initialized, which is likely due to #1038. @dscorbett
I thought I verified that the default constructor would take care of that, but apparently not.

I'm using MallocScribble on OS X, which sets uninitialized heap memory to 0xAA:

[DFHack]# lua ~bld.flags
<building_flags: 0x1272e9c0>
exists                 	 = false
site_blocked           	 = true
room_collision         	 = false
3                      	 = true
justice                	 = false
almost_deleted         	 = true
in_update              	 = false
from_worldgen          	 = true
8                      	 = false
9                      	 = true
10                     	 = false
11                     	 = true
12                     	 = false
13                     	 = true
14                     	 = false
15                     	 = true
16                     	 = false
17                     	 = true
18                     	 = false
19                     	 = true
20                     	 = false
21                     	 = true
22                     	 = false
23                     	 = true
24                     	 = false
25                     	 = true
26                     	 = false
27                     	 = true
28                     	 = false
29                     	 = true
30                     	 = false
31                     	 = true

I'm guessing a combination of site_blocked and almost_deleted is bad.

[lethosor]

Yeah, I ran a test with tile_designation in a standalone executable and confirmed that the bitfield is uninitialized.

It would be nice to keep the lack of a default constructor, though. Maybe we could add bitfield initialization to the (generated) constructors of structures that contain bitfields, though.

[lethosor]

I'm trying to change this section to zero-initialize bitfields. The issue is that in library/include/df/codegen.out.xml, building::flags appears as:

<ld:field name="flags" type-name="building_flags" ld:level="1" ld:meta="global"/>

I'm not sure why ld:meta is "global". In theory, it would be possible to figure out that building_flags refers to a bitfield, but I'm not sure how to do that either. I'm guessing that this section of lower-1.xslt could be the problem.
@angavrilov?

[lethosor]

I couldn't figure out why ld:meta="global", but I did manage to get a proper ld:subtype attribute generated ("bitfield" in this case) by changing

<compound name='flags' type-name='building_flags'/>

to

<bitfield name='flags' type-name='building_flags'/>

I don't know if this will affect the Lisp tool, but the Perl scripts seem to be able to handle the change just fine, and generate code to initialize the bitfield in the constructor appropriately.

[lethosor]

Looks fixed to me.