View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011638 | Dwarf Fortress | Miscellaneous Crashes | public | 2020-10-17 11:58 | 2020-10-28 09:17 |
| Reporter | daishi5 | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows 10 | OS Version | Build 18363 |
| Product Version | 0.47.04 | ||||
| Summary | 0011638: Crash in early spring unknown cause | ||||
| Description | My game is crashing every time within 3 months of the latest seasonal save, usually within a couple weeks. I am using the latest lazy newb pack. I have tried disabling DF hack, and it still reliably crashes. I have also tried running it with no utilities or third party programs, still crashes. I have checked all the equipment lists for my dwarves, and only valid item types and artifacts show up on the lists of possible items. Running the DFHack script to check for invalid equipment returns no errors. I have tried suspending all jobs, turning all meeting areas to citizens only, disabling all labor. The game ran much longer when I disabled all labors and suspended all jobs. However, once I loaded the labors again and they started working, the game crashed in month 3. Its possible that some combination of labor changes and job changes might prevent the crash (and therefore identify what caused the crash), but it can take up to an hour for the game to crash, so it seems unfeasible to work through all the iterations carefully. | ||||
| Steps To Reproduce | The quickest and most reliable way to make it crash seems to be to load the game. A human attack will come in a few days, when it comes: Change the civilian alert to "attack" and then station the 4 squads of dwarves somewhere. I usually station them near the trading depot (hotkey f2.) | ||||
| Additional Information | Save file here: https://dffd.bay12games.com/file.php?id=15254 | ||||
| Tags | No tags attached. | ||||
|
|
I failed to find the reason for the crash. The time I hooked up a debugger to the game it tried to access a null pointer. |
|
|
The crash seems to have happened within the code that generates the announcement "[unit] has revealed the presence of [artifact] to [unit].", and it crashed while retrieving some information from unit 5364 (Stukos Thikutog, deceased Axedwarf). The information being fetched was from a field which DFHack currently knows as "unitst.enemy.unk_v40_sub3.unk_7" - exactly what that field's real name is, I don't know, but it's supposed to be a pointer to another data structure but that pointer is NULL. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-10-17 11:58 | daishi5 | New Issue | |
| 2020-10-18 01:53 | PatrikLundell | Note Added: 0040767 | |
| 2020-10-28 09:17 | Quietust | Note Added: 0040775 | |
| 2020-10-28 09:18 | Quietust | Note Edited: 0040775 | |
| 2020-10-28 09:25 | Quietust | Note Edited: 0040775 | |
| 2020-10-28 09:29 | Quietust | Note Edited: 0040775 | |
| 2020-10-28 10:46 | Quietust | Note Edited: 0040775 |
