Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010939Dwarf FortressTechnical -- Generalpublic2018-10-24 15:422020-01-29 00:38
Assigned ToLoci 
PlatformLinuxOSUbuntuOS Version16.04.5 LTS
Product Version0.44.12 
Target VersionFixed in Version0.47.01 
Summary0010939: segfault on "Saving fortress information" when trying to save, reproducible via savestate
DescriptionGame reproducibly crashes with segmentation fault when trying to save loaded savestate. Crash occures on the "Saving fortress information" stage.

It also crashes on this savestate after a few minutes of playing, though this is less consistent(or maybe I just not waited enough)
Steps To Reproduce* Load save
* <ESC>
* "Save Game"
* crash
Additional Information [^]
TagsNo tags attached.
Attached Files

- Relationships
related to 0011030resolvedToady One Crash on save, does not save 
related to 0011035new Crashes every time during save 
related to 0011044new Crash on save 
related to 0010499confirmedlethosor Crash 
related to 0010742resolvedToady One Game Crashes When Dwarves Return From a Raid 
related to 0010903resolvedToady One crash on save 
related to 0011104new DF crashes it try to save right after loading or wait several game days 
related to 0011082new Saving always crashes at "Saving fortress information" 

-  Notes
Loci (manager)
2019-02-02 10:31

The posted save crashes for me saving on windows, too.

Here is another save that appears to be the same problem (or, at least, crashes in the same manner): [^]
Darxus (reporter)
2019-02-21 05:28

My crash looks more related to this one, consistent segfault during save: 0011035
Darxus (reporter)
2019-02-22 11:10

Has anybody checked if these other three saves have corrupted military equipment, like 0011014 ?

I'm wondering if they're the same bug, crashing at different times.

How would I check this myself?
risusinf (reporter)
2019-02-22 22:17
edited on: 2019-02-23 22:52

They have not. There is no strong evidence to link these issues up.


I can confirm though that the save from OP crashes on play too after few minutes. I'll keep looking into it.


Ok, it crashes both on save and on play in five minutes or so. There is a single military dwarf, disbanding him doesn't do the trick, and it seems like raiding was never done in this fort, so it has nothing to do with 0011014 (gdb too says it's something different). Then i let the game run for 4,5 minutes, and tried to save to get faster crash. I forgot it's going to segfault on save as well, however it didn't. Save now loads, runs and saves again normally.

risusinf (reporter)
2019-02-25 00:26
edited on: 2019-03-01 23:44

Here's a reliably reproducible pattern that works for me.

1. Load => Save => Crash on "Saving fortress information"
2. Load => Unpause for a few seconds => Save => Same crash
3. Load => Exterminate specific unit => Unpause for a few seconds (needed for the unit to die off) => Save => No crash

Specific units are:
Save from OP -- Geral Onruofo the human dancer (her death also prevents 5min play crash)
Save from the first comment -- Bembul Ikthagsigun the baron

I don't see a point in checking two other saves (0011035 and 0011030 -- should be similar according to debugger output), 'cause i can't figure out in what way those units are broken, or they are fine but are adjacent to some corrupted structure or algorithm. Is there some kind of a magic spell to detect unusual unit attributes or at least list them all?

Also there are two more saves that segfault (on play, not on save) and get better after specific unit gets removed -- 0010499 and 0010742. The former is more straightforward though (corrupted inventory). See my comments there for details. Also 0010143 is worth checking (bugged inventory as well).


Missed out, 0010903 would be the fifth one, crashes on save, same backtrace.
0011044 also.

Toady One (administrator)
2020-01-29 00:37

This one was similar to 0010742, but not the same - here the dancer had corrupt criminal data.

- Issue History
Date Modified Username Field Change
2018-10-24 15:42 uquendo New Issue
2019-02-02 10:31 Loci Note Added: 0039176
2019-02-02 10:31 Loci Assigned To => Loci
2019-02-02 10:31 Loci Status new => confirmed
2019-02-16 08:49 Loci Relationship added parent of 0011030
2019-02-21 05:28 Darxus Note Added: 0039231
2019-02-22 11:10 Darxus Note Added: 0039236
2019-02-22 22:17 risusinf Note Added: 0039237
2019-02-23 03:01 risusinf Note Edited: 0039237 View Revisions
2019-02-23 22:52 risusinf Note Edited: 0039237 View Revisions
2019-02-24 11:50 Loci Relationship added parent of 0011035
2019-02-25 00:26 risusinf Note Added: 0039240
2019-02-25 02:01 risusinf Note Edited: 0039240 View Revisions
2019-03-01 23:44 risusinf Note Edited: 0039240 View Revisions
2019-03-02 11:45 Loci Relationship added parent of 0011044
2019-04-14 11:09 Loci Relationship added related to 0011082
2019-04-14 11:21 Loci Relationship added related to 0010499
2019-04-14 11:21 Loci Relationship added related to 0010742
2019-04-14 11:22 Loci Relationship added related to 0010903
2019-04-16 22:38 risusinf Issue Monitored: risusinf
2019-07-11 18:29 Loci Relationship added parent of 0011104
2020-01-29 00:37 Toady One Note Added: 0039686
2020-01-29 00:37 Toady One Status confirmed => resolved
2020-01-29 00:37 Toady One Fixed in Version => 0.47.01
2020-01-29 00:37 Toady One Resolution open => fixed
2020-01-29 00:38 Toady One Relationship replaced related to 0011035
2020-01-29 00:38 Toady One Relationship replaced related to 0011044
2020-01-29 00:38 Toady One Relationship replaced related to 0011104
2020-01-29 00:38 Toady One Relationship replaced related to 0011030
2020-01-29 01:40 risusinf Issue End Monitor: risusinf

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker