Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011014Dwarf FortressDwarf Mode -- Militarypublic2019-01-27 17:392019-02-20 16:09
ReporterLoci 
Assigned ToLoci 
PriorityhighSeveritycrashReproducibilitysometimes
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version0.44.12 
Target VersionFixed in Version 
Summary0011014: Reproducible crash from corrupted military equipment lists
DescriptionThe attached save is on the 25th of Mid-Autumn. It crashes reliably at the end of the month.

I haven't been able to isolate the source of the crash.

On a potentially-related note, the save shows two merchants leading pack animals into dead-end rooms of the fortress.
Additional Informationhttp://dffd.bay12games.com/file.php?id=14213 [^]


*edit: risusinf identified this crash as a corruption of military equipment and linked multiple other examples in note 0011014:0039186 below.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0039161)
PatrikLundell (reporter)
2019-01-28 00:36
edited on: 2019-01-28 00:37

I've tried the save twice, without crashing in either case, so I assume the issue requires a specific environment.
I'm on Windows 10.1 using the LNP r05.

In my first attempt I had DFHack enabled. The merchant ran back and forth like visitors do when trying to leave a fortress whose entrances are all locked up due to a siege so there's no path out. Eventually the merchant disconnected from the yak in a room in the fortress without any indication of a reason (no fighting or fear, as far as I could see) and eventually left through a cavern together with the swordsman. When I killed the game around the 10:th the yak remained in the fortress labeled as "Friendly" rather than "Merchant".

In my second run I'd disabled DFHack (and changed print mode from TwbT to 2D). In this run the merchant left the fortress on the surface together with the yak at around the 4:th. The swordsman turned to "Friendly", but left shortly thereafter.

If it's of interest, I can let the fortress run on its own past the troublesome end of the month and upload the progressed save to allow you to continue (if so, please specify a time you'd like the save to be progressed to).

(0039175)
Loci (manager)
2019-02-02 10:02
edited on: 2019-02-02 10:05

Thank you for taking a look at the save. It crashes reliably for me using vanilla windows x32, vanilla linux x64, and vanilla windows x64 under wine. The only common thread I see is an AMD processor.

Given the nature of the failure, I suspect the crash will likely recur at the end of subsequent months, but if you are willing to post a save after the first of Timber I'll test that hypothesis.

(0039181)
PatrikLundell (reporter)
2019-02-03 00:37

http://dffd.bay12games.com/file.php?id=14227 [^] progressed to the second of Timber.
I've done nothing except looking at Announcements from time to time to check progress, so no actions have been taken (I haven't even checked on the erratic merchant this time).

My PC has an Intel processor, so that doesn't contradict the hypothesis of the issue being AMD related.
(0039183)
risusinf (reporter)
2019-02-03 08:35
edited on: 2019-02-03 21:35

Does segfault on lin32 old Intel CPU and doesn't on win64 modern Intel CPU (noticed a moment of stuttering though), but that's not the point. Crash isn't time fixed and can be avoided. It doesn't happen when all squads are disbanded, so i believe the issue is the same as i reported in 0010880:0038940, namely military equip lists being completely fucked up. Illustration: https://i.imgur.com/VKTGasZ.png [^] (it is relatively easy to check any crashy save for this to be the reason)

Probably this should be prioritized due to its unholy ugliness and that the issue is likely to cover several tickets on the tracker, not to say it breaks gameplay, you can't have proper militia anymore.

Next day edit: I'm going to check few more unresolved crash reports to see how widespread the issue could be.

(0039185)
PatrikLundell (reporter)
2019-02-05 03:52

I just had a case of this crash myself a couple of seconds after quicksaving. Disbanding all squads did indeed allow the game to progress, while disbanding no single squad did. Checking specific Armor showed a bunch of written contents (all "item_bookst") at the bottom (and the one I checked wasn't in my fortress). The only category whose specific item list wasn't cluttered with "item_bookst" was the Weapon one, which doesn't seem to be broken (in my particular case). It can be noted that the junk items at the end differ between the equipment categories, but contain at least one item in common, and probably several ones. This item also appears multiple times in the lists (at least most of them). However, progressing the game for a few seconds and attempting to create a squad shows that the categories have not been repaired, but retain the junk items. Since my fortress was built on the idea of conquering goblin sites, this is really a fatal blow to it.

All the "books" I've looked at have had low item Ids, typically around 6-700.
(0039186)
risusinf (reporter)
2019-02-05 08:46

Few saves that follow the same pattern
All tests were carried out on intel i7 lin64 platform (through ssh) with vanilla DF 0.44.12

Read each paragraph line by line as:
- Ticket/comment ID
- Result of the first run
- Actions on the second run to avoid and reproduce crash
- Garbage in equip lists ( [m]->[e]->[A|L|H|G|B|S|W]->"specific ..." )
- Additional notes

0011014
crash time ~1min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 2min; quick crash after creating 1 unit squad with "footwear" equipped
Helm=Ivaklasod x1; Boots=Ivaklasod x4; Shield=Ivaklasod x1
Ivaklasod is a serpentine slab, first item in the legends mode's Codices menu
(Garbage items come and go with time, compare https://i.imgur.com/VKTGasZ.png [^] which was made on the first run before unpausing the game)

0011004
crash time ~2min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 5min; quick crash after creating 1 unit squad with "armor" equipped
Armor=Måmgozôm îbmat Lisid x3; Boots=Måmgozôm îbmat Lisid x100, ≡large smoky quartz≡ x2, Soshornalthish x1
Måmgozôm îbmat Lisid is a sterling silver slab, first item in the legends mode's Codices menu

0010880:0038940 (win64 same CPU does crash)
crash time <1min
reload and disband all squads before unpausing; no crash after 1min; quick crash after creating 1 unit squad with "handwear" equipped
Legs=Sesiwerima Obenirifi x1, The World Without The Wind x1; Gloves=Sesiwerima Obenirifi x2, Classic Fikod Gearedfocused x1, Life With Beakers x1
Sesiwerima Obenirifi is a microcline slab, first item in the legends mode's Codices menu
(this one is mine, crashes the same way on lin32 old Intel CPU platform)

0010880:0038892
crash time <2min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 5min; quick crash after creating 1 unit squad with "headwear" equipped
Helm=Slömodoxxo x1; Gloves=Slömodoxxo x2
Slömodoxxo is an hornblende slab, second item in the legends mode's Codices menu

0010880
crash time <5min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 10min; quick crash after trying to check "specific armor" list
Armor=Thafenelara x1
Thafenelara is a rhyolite slab, first item in the legends mode's Codices menu

0010868
crash time <1min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 1min; quick crash after creating 1 unit squad with "armor" equipped
Armor=Okoshfeb x2; Legs=Okoshfeb x2; Helm=Okoshfeb x3; Gloves=Okoshfeb x1; Shield=Okoshfeb x4; Weapon=Okoshfeb x2
Okoshfeb is a native gold slab, first item in the legends mode's Codices menu

Timings and the crashes itself (which might not happen at all) depend on CPU performance and architecture (and god knows what else, OS for sure)
All crashes are SEGFAULT
The issue may be responsible for multiple raid-related reports, i haven't checked those yet though (tested saves has no "travelling" dwarves), and if so this bug grows even bigger in its terrible awfulness (no, i cannot approve that Windows seemingly tends to sweep under the rag flawed code)
(0039187)
Loci (manager)
2019-02-05 13:43

@PatrikLundell: Thank you for uploading the advanced save! I was able to run it without crash for over a year, so loading and resaving a few days later somehow fixed the corruption, at least temporarily.

@risusinf: Thank you for the detailed analysis! This issue is likely to be one of the first few bug-fixes after the upcoming release, and your efforts will help Toady identify and correct the problem.
(0039191)
risusinf (reporter)
2019-02-06 08:04

More abominations

0010975
crash time ~1min
reload and disband all squads before unpausing; no crash after 2min; quick crash after trying to check "specific gloves" list
NO visual garbage in equip lists
0010579 might be the same, but it crashed only once in multiple attempts

0010911
crash time <1min
reload and disband all squads before unpausing (including one with travelling dwarves); no crash after 2min; no crash after creating 1 unit squad with "armor" equipped, then adding "legwear", then "helm", but eventually crashed after adding "handwear"
Armor=For The Love Of The Individual x15, For The Love Of The Fortress x1; Legs=For The Love Of The Individual x7; Helm=For The Love Of The Individual x7; Gloves=An Offering To The Truth x1; Boots=For The Love Of The Individual x15, Taremimustteling x2; Shield=For The Love Of The Individual x6
Taremimustteling is a native copper slab, first item in the legends mode's Codices menu

0010894
crash ~2min, soon after a squad returns from mission
disbanding squads except the returning one still crashes, while disbanding it too right on arrival keeps the game running; quick crash after creating 1 unit squad with "armor" equipped
Armor=Asolum âtrid Vetek x2; Legs=Asolum âtrid Vetek x5; Helm=Asolum âtrid Vetek x5; Gloves=Asolum âtrid Vetek x2; Boots=Asolum âtrid Vetek x10; Shield=Asolum âtrid Vetek x5; Weapon=Asolum âtrid Vetek x1
Asolum âtrid Vetek is a diorite slab, first item in the legends mode's Codices menu

0010851
crash time <1min
after disbanding squads game goes past, and goblins arrive; couldn't reproduce crash by adding equip categories for 1 unit squad
Armor=Slatsutosnak x1; Legs=Slatsutosnak x1; Helm=Slatsutosnak x1; Gloves=For The Love Of The Tower x1, Thoughts On The Elf x1; Shield=Slatsutosnak x2; Weapon=Slatsutosnak x2
Slatsutosnak is bituminous coal slab, first item in the legends mode's Codices menu

That would be all for my crusade against evil, but i guess there is a huge ton of saves affected, as the most popular Windows platform just keeps it low profile, and sometimes the impact is not too harsh
(0039193)
Gregamesh (reporter)
2019-02-06 22:49
edited on: 2019-02-07 11:06

Going to add to this because I realized that the last issue I posted is actually another example of equipment list corruption:

All are run on DF 0.44.12 on Mac OS High Sierra, version 10.13.6. I could try again with an updated OS, but I doubt it will change things.

Original report of mine: 0011025
Crashes in about 1 min (2 in-game days, exactly)
Disbanding all squads does not result in an immediate crash.

Corrupted armors are as follows:
Armor=Snogongstekug x1, Unookal x1; Legs=no corruption; Helm=Unookal x1, Inquires on the Center x1; Gloves=Snogongstekug x2, Unookal x1; Boots=Snogongstekug x1, Unookal x1; Shields=no corruption; Weapons=no corruption.
Unookul is the first entry in Codices, etc; it is an orthoclase slab.
Snogongstekug is the second entry; it is a chalk slab.

A save created by retiring the fort at this point and unretiring does not have any armor list corruption. I have not tested if armor corruption will eventually develop in that version of the save.


By saving repeatedly on the date when a segfault would occur, I was able to push the save until 773-8-11. Advanced version of the save can be downloaded here: http://dffd.bay12games.com/file.php?id=14236. [^] At this point, saving on or after 8-12 results in the following error:
[DFHack]# /Users/{my directory}/Desktop/df_osx/dfhack: line 15: 5033 Abort trap: 6 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

Letting the game run instead, it crashes around 8-17 with the following error:
[DFHack]# /Users/{my directory}/Desktop/df_osx/dfhack: line 15: 4930 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@“
Note: the 4-digit number changes between each iteration of the crash, but the rest of the message remains the same.

Disbanding all squads but the eighth (it is leaving to go on a raid, and the commander is off-site) allows normal saving to occur after the 12th. Squads can be recreated after this point and saved normally. Squads were recreated using a premed equipment template with parts from all categories. The game still segfaults around 8-17.

The corrupted armors in this version of the save are:
Armor=Snogongstekug x1, Unookal x1; Legs=no corruption; Helm=Unookal x1, Inquires on the Center x1; Gloves=Snogongstekug x4, Unookal x2; Boots=Snogongstekug x1, Unookal x1; Shields=no corruption; Weapons=no corruption.

(0039207)
risusinf (reporter)
2019-02-11 22:56
edited on: 2019-02-13 03:15

Regarding possible obstructions of the raid system

0010951
Resaving postpones crashing, and equip lists are heavily corrupted (behaviour similar to 0011014). This resave (made immediately after the conquest of Mighthorror) -- http://dffd.bay12games.com/file.php?id=14246 [^] -- reliably crashes for me in under 3min (44.12@lin64, win64 doesn't seem to crash at all). Military layout is complicated. One squad is out for a mission with two recruits falling behind, one of them has no military equipment and is about to pick it up. Disbanding all other squads (including one with travelling dwarves from the previous mission) makes it crash even faster (<1.5min). Removing the guy without equipment from the squad doesn't change anything, removing both recruits allows the game to show message about successfull conquest and then crash shortly. After that my best guess was that the travelling squads can actually trigger the equipment bug, or there is something else, so i kept digging. Weirdly enough, i discovered that terminaton of all of the yaks at once allows to progress for 5min and maybe more. However, killing off yaks one by one didn't make the crash go away. More to this, guy from The Eradicators, position 1 and another one from The Crosshoes, position 2 are assigned to equip two "missing item" each; and all members of The Golden Legion are assigned to wear socks, which is weird. Related or not, but it's a total mess.

Also there is a small inconsistency in viewing departed squads on the military screen: [p]ositions shows members names with (travelling) postfix while [e]quip instead of that prints VACANT/AVAILABLE.

============

EDIT:
After getting familiar with 0010369 i tend to assume that all these memory corruptions are actually just a further development of some general flaw in the raiding system itself, as that issue wasn't solved but patched out by checking and removing duplicate items.

(0039229)
Darxus (reporter)
2019-02-20 16:09

Gregamesh said mine might be related: 0011035

I load it, save immediately, and it crashes, every time. They mentioned I have armor corruption similar to stuff mentioned here. On my dwarves out on a raid.

- Issue History
Date Modified Username Field Change
2019-01-27 17:39 Loci New Issue
2019-01-27 17:44 Loci Additional Information Updated View Revisions
2019-01-28 00:36 PatrikLundell Note Added: 0039161
2019-01-28 00:37 PatrikLundell Note Edited: 0039161 View Revisions
2019-02-02 10:02 Loci Note Added: 0039175
2019-02-02 10:03 Loci Description Updated View Revisions
2019-02-02 10:05 Loci Note Edited: 0039175 View Revisions
2019-02-03 00:37 PatrikLundell Note Added: 0039181
2019-02-03 01:53 risusinf Note Added: 0039182
2019-02-03 08:35 risusinf Note Deleted: 0039182
2019-02-03 08:35 risusinf Note Added: 0039183
2019-02-03 08:36 risusinf Note Edited: 0039183 View Revisions
2019-02-03 21:34 risusinf Note Edited: 0039183 View Revisions
2019-02-03 21:35 risusinf Note Edited: 0039183 View Revisions
2019-02-05 03:52 PatrikLundell Note Added: 0039185
2019-02-05 08:46 risusinf Note Added: 0039186
2019-02-05 13:43 Loci Note Added: 0039187
2019-02-05 13:43 Loci Assigned To => Loci
2019-02-05 13:43 Loci Priority normal => high
2019-02-05 13:43 Loci Reproducibility always => sometimes
2019-02-05 13:43 Loci Status new => confirmed
2019-02-05 13:43 Loci Category General => Dwarf Mode -- Military
2019-02-05 13:43 Loci Summary Reproducible crash at end of month => Reproducible crash from corrupted military equipment lists
2019-02-05 13:43 Loci Additional Information Updated View Revisions
2019-02-06 08:04 risusinf Note Added: 0039191
2019-02-06 22:49 Gregamesh Note Added: 0039193
2019-02-06 22:49 Gregamesh Note Edited: 0039193 View Revisions
2019-02-06 22:50 Gregamesh Note Edited: 0039193 View Revisions
2019-02-07 11:06 Gregamesh Note Edited: 0039193 View Revisions
2019-02-11 22:56 risusinf Note Added: 0039207
2019-02-12 09:29 risusinf Note Edited: 0039207 View Revisions
2019-02-13 03:12 risusinf Note Edited: 0039207 View Revisions
2019-02-13 03:15 risusinf Note Edited: 0039207 View Revisions
2019-02-15 02:07 risusinf Issue Monitored: risusinf
2019-02-20 16:09 Darxus Note Added: 0039229


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker