Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011025Dwarf FortressDwarf Mode -- Invasionspublic2019-02-05 17:542019-02-06 19:19
ReporterGregamesh 
Assigned To 
PriorityhighSeveritycrashReproducibilityalways
StatusnewResolutionopen 
PlatformOSXOSHigh SierraOS Version10.13.6
Product Version0.44.12 
Target VersionFixed in Version 
Summary0011025: Invading army causes crash around the same time a hillocks is established.
DescriptionFortress has been surviving with no major issues for over 15 years. After several normal invasions, a new invasion comes that crashes DF. After quite a bit of testing, the only possible link identified is that a dwarven hillocks is established seemingly at the exact same time that a dwarven hillocks is established.

Tested fixes:
-Launching DF with either the native DF launcher or the DFHack Launcher: Both result in crash
-Disabling invaders: army still spawns, and crashes
-Disabling compressed saves, saving, and relaunching: crashes
-Launching save in a fresh install of DF: still crashes
-Altering the graphics settings of DF: still crashes
-Retiring and unretiring the fortress: Avoids the crash, but you then have to deal with all the bugs associated with unretiring

Note that the hillocks establishment doesn't always appear before the army invades; the game crashes whether or not it is announced, but both occur on the same in-game day.

The save itself doesn't seem to be corrupted, just that the invasion causes a crash.

The raws have NOT been edited in any way.

Launching from DFHack and waiting for the crash causes the following to appear in the terminal:

[DFHack]# /Users/{user directory goes here}/Desktop/df_osx/dfhack: line 15: 67525 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

This doesn't appear to be related to DFHack, as the crash still appears in unmodified DF.
Steps To ReproduceEither:

Naturally have a dwarven hillocks be established at about the same time as when an army invades.

Or:

From the save included in Additional Information, wait for two in-game days (from 10-6 to 10-8) for the army to invade, then wait another few seconds after unpausing for the crash.
Additional InformationSave can be downloaded here:
http://dffd.bay12games.com/file.php?id=14232 [^]
TagsNo tags attached.
Attached Files

- Relationships
child of 0011014confirmedLoci Reproducible crash from corrupted military equipment lists 

-  Notes
(0039188)
Gregamesh (reporter)
2019-02-05 20:09
edited on: 2019-02-05 20:11

 Update with four more tested methods:
-Killing invaders by means of DFHack's exterminate command, units die normally but game still crashes after a few seconds
-Setting invader caps to 1: full army still spawns, crashes
-Restarting the computer and relaunching DF, crashes
-Saving between the hillocks announcement and the arrival of the siege, doesn't crash. Note: the invader cap was still set to 1, but the full army of about 30 units spawned.

This leads me to believe that the issue does have some relation to the hillocks establishment, though how it then affects the spawn size of an army and causes it to ignore d-init settings is not clear (it is possible that the siege is technically a "smaller raid" which are unaffected by the numerical invader cap, but should still be prevented by disabling invaders).
(0039189)
PatrikLundell (reporter)
2019-02-05 23:56

 Armies are sent out at the turn of the season and arrive at their targets <travel time> days later. If you save and change the siege related parameters in between the army departing (such as with an automatic seasonal save) and its arrival it's not unreasonable for the changed parameters not to retroactively affect the armies already generated and in transit.

Note that enemies goaded into attacking you through raiding may use a different timing than normal neighbor attacks. I don't have any experience of such sieges, though.
(0039192)
Gregamesh (reporter)
2019-02-06 19:19
edited on: 2019-02-07 10:10

 After some more testing, this issue seems to actually be a duplicate of what was identified in issue 0011014: certain artifacts are being inserted into specific equipment lists, causing a segfault.

Illustration of the issue for this world is here: https://imgur.com/a/loxIeeN [^] Note: this is from a more advanced version of the save; I find that saving either before the date, or on the date, when a segfault occurs will prevent that segfault, though this is both a tedious method and ultimately unfeasible due to the random timing of segfaults.

- Issue History
Date Modified Username Field Change
2019-02-05 17:54 Gregamesh New Issue
2019-02-05 20:09 Gregamesh Note Added: 0039188
2019-02-05 20:09 Gregamesh Note Edited: 0039188 View Revisions
2019-02-05 20:09 Gregamesh Note Edited: 0039188 View Revisions
2019-02-05 20:11 Gregamesh Note Edited: 0039188 View Revisions
2019-02-05 23:56 PatrikLundell Note Added: 0039189
2019-02-06 19:07 Gregamesh Issue Monitored: Gregamesh
2019-02-06 19:07 Gregamesh Issue End Monitor: Gregamesh
2019-02-06 19:07 Gregamesh Issue Monitored: Gregamesh
2019-02-06 19:19 Gregamesh Note Added: 0039192
2019-02-06 19:20 Gregamesh Note Edited: 0039192 View Revisions
2019-02-06 19:20 Gregamesh Note Edited: 0039192 View Revisions
2019-02-06 20:24 lethosor Note Edited: 0039192 View Revisions
2019-02-07 10:10 Gregamesh Note Edited: 0039192 View Revisions
2019-02-24 12:07 Loci Relationship added child of 0011014

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker