View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011549 | Dwarf Fortress | Miscellaneous Crashes | public | 2020-05-25 20:40 | 2021-01-22 15:23 |
Reporter | antielectron | Assigned To | lethosor | ||
Priority | high | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Windows | OS | Windows 10 Pro | OS Version | 1909 |
Product Version | 0.47.04 | ||||
Fixed in Version | 0.47.05 | ||||
Summary | 0011549: Crash when off-site werecreature gives birth | ||||
Description | Game crashes after date: 251-3-23 This was my first dwarf fortress run ever :( Any chance I can continue it? | ||||
Steps To Reproduce | Load the save game below and let the time get to 251-3-23 (take a couple of minutes). http://dffd.bay12games.com/file.php?id=15092 | ||||
Additional Information | I tried varying what I did in-game to get around the crash, but no good. Also tried disbanding my squads and setting my pyLNP visitor cap to zero - because I saw in forums that that has helped other people, but that attempts didn't work for me. More saves: https://dffd.bay12games.com/file.php?id=15114 (0011560, 0.47.04) https://dffd.bay12games.com/file.php?id=15134 (0011571, 0.47.04) | ||||
Tags | Save Included, werebeast | ||||
|
Repeated the crash on my Win64 system. I found no zero size creatures or equipment corruption. Hooking up a debugger to DF shows the crash is caused by an access violation trying to read location 0xFFFFFFFFFFFFFFFF. |
|
This appears to be the exact same crash seen in 0011571 - a Human named "Olo Lapaslibtu" (unit 5349, histfig 40304) is giving birth to a child while transformed into a Wereantelope. |
|
Since this is the oldest of the three instances of this issue identified (so far), I'm planning on consolidating any other discovered duplicates here (even if they're older). I was also able to reproduce (on Linux, 0.47.04 64-bit) |
|
The problem seems to be that the units are trying to give birth to MALE offspring (with caste id == 1), even though werecreatures only have a single DEFAULT caste (with caste id == 0). |
|
Changing the death time of the historical figure to the current time (i.e. shortly before the crash would occur) with DFHack allows the save to proceed beyond the crash point, but the side effects of the unrecorded death of the HF are unknown. (As 0011571 has been resolved, I can't add a comment to it. For anyone else looking at the corresponding save, the histfig id given by Quietust has the last two digits swapped, it should have been 78836.) |
|
I have crash that looks similar. How I could confirm this? Is there a way to check if it is the case by using dfhack lua interface? |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-05-25 20:40 | antielectron | New Issue | |
2020-05-26 00:04 | PatrikLundell | Note Added: 0040568 | |
2020-07-03 08:57 | Quietust | Note Added: 0040609 | |
2020-07-03 08:58 | Quietust | Note Edited: 0040609 | |
2020-07-03 08:58 | Quietust | Note Edited: 0040609 | |
2020-07-03 08:59 | lethosor | Relationship added | has duplicate 0011560 |
2020-07-03 08:59 | lethosor | Relationship added | has duplicate 0011571 |
2020-07-03 09:01 | lethosor | Additional Information Updated | |
2020-07-03 09:03 | lethosor | Note Added: 0040611 | |
2020-07-03 09:03 | lethosor | Assigned To | => lethosor |
2020-07-03 09:03 | lethosor | Status | new => acknowledged |
2020-07-03 09:03 | lethosor | Tag Attached: Save Included | |
2020-07-03 09:13 | lethosor | Tag Attached: werebeast | |
2020-07-03 09:13 | lethosor | Summary | Reliable Crash => Crash when off-site werecreature gives birth |
2020-07-03 09:14 | Quietust | Note Added: 0040612 | |
2020-07-03 09:17 | lethosor | Status | acknowledged => confirmed |
2020-07-03 09:18 | lethosor | Note Edited: 0040611 | |
2020-07-08 03:26 | PatrikLundell | Note Added: 0040618 | |
2020-08-08 10:54 | lethosor | Relationship added | has duplicate 0011573 |
2020-11-16 11:42 | psychowico | Note Added: 0040794 | |
2021-01-21 19:25 | lethosor | Sticky Issue | No => Yes |
2021-01-22 15:23 | Toady One | Status | confirmed => resolved |
2021-01-22 15:23 | Toady One | Fixed in Version | => Next Version |
2021-01-22 15:23 | Toady One | Resolution | open => fixed |