View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011025 | Dwarf Fortress | Dwarf Mode -- Invasions | public | 2019-02-05 17:54 | 2019-02-06 19:19 |
| Reporter | Gregamesh | Assigned To | |||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | OSX | OS | High Sierra | OS Version | 10.13.6 |
| Product Version | 0.44.12 | ||||
| Summary | 0011025: Invading army causes crash around the same time a hillocks is established. | ||||
| Description | Fortress 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 Reproduce | Either: 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 Information | Save can be downloaded here: http://dffd.bay12games.com/file.php?id=14232 | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
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. |
|
|
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. |
| 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 | |
| 2019-02-05 20:09 | Gregamesh | Note Edited: 0039188 | |
| 2019-02-05 20:11 | Gregamesh | Note Edited: 0039188 | |
| 2019-02-05 23:56 | PatrikLundell | Note Added: 0039189 | |
| 2019-02-06 19:19 | Gregamesh | Note Added: 0039192 | |
| 2019-02-06 19:20 | Gregamesh | Note Edited: 0039192 | |
| 2019-02-06 19:20 | Gregamesh | Note Edited: 0039192 | |
| 2019-02-06 20:24 | lethosor | Note Edited: 0039192 | |
| 2019-02-07 10:10 | Gregamesh | Note Edited: 0039192 | |
| 2019-02-24 12:07 | Loci | Relationship added | child of 0011014 |
