New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ab9rf opened this Issue Dec 16, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@ab9rf
Member

ab9rf commented Dec 16, 2016

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 lethosor added the bug label Dec 16, 2016

@lethosor

This comment has been minimized.

Member

lethosor commented Dec 16, 2016

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?

@lethosor lethosor added this to the 0.43.05-r1 milestone Dec 16, 2016

@ab9rf

This comment has been minimized.

Member

ab9rf commented Dec 16, 2016

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

This comment has been minimized.

Member

lethosor commented Dec 18, 2016

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

@lethosor lethosor self-assigned this Dec 18, 2016

@lethosor

This comment has been minimized.

Member

lethosor commented Dec 18, 2016

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

This comment has been minimized.

Member

lethosor commented Dec 18, 2016

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 lethosor changed the title from buildingplan: planning mode builds fail sometimes to buildingplan: planning mode builds fail sometimes - flags bitfield not initialized Dec 18, 2016

@lethosor

This comment has been minimized.

Member

lethosor commented Dec 18, 2016

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

This comment has been minimized.

Member

lethosor commented Dec 18, 2016

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 added a commit to DFHack/df-structures that referenced this issue Dec 18, 2016

Initialize all bitfields to zero in generated constructors
This currently requires bitfields to be defined with the <bitfield> tag -
currently, all bitfield fields with a type-name use <compound> instead.

DFHack/dfhack#1047 (partial fix)
DFHack/dfhack#1038
#169
#171

ab9rf added a commit to ab9rf/df-structures that referenced this issue Dec 18, 2016

ab9rf added a commit to ab9rf/dfhack that referenced this issue Dec 19, 2016

lethosor added a commit to DFHack/df-structures that referenced this issue Dec 27, 2016

lethosor added a commit that referenced this issue Dec 27, 2016

lethosor added a commit to DFHack/df-structures that referenced this issue Dec 28, 2016

lethosor added a commit to DFHack/df-structures that referenced this issue Dec 28, 2016

lethosor added a commit to DFHack/df-structures that referenced this issue Dec 28, 2016

Allow unions of types with non-trivial constructors (e.g. bitfields)
This should resolve the issue behind #169 and #171, as well as the issues
created by that change (DFHack/dfhack#1047, DFHack/dfhack#1050,
DFHack/dfhack#1052).

This reverts commits 22819e2 and
2700f2e.

lethosor added a commit that referenced this issue Dec 28, 2016

@lethosor lethosor added the structures label Dec 28, 2016

@lethosor

This comment has been minimized.

Member

lethosor commented Dec 28, 2016

Looks fixed to me.

@lethosor lethosor referenced this issue Dec 31, 2016

Closed

Fix autochop #1030

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment