View Issue Details

IDProjectCategoryView StatusLast Update
0010939Dwarf FortressTechnical -- Generalpublic2020-01-29 00:38
Reporteruquendo Assigned ToLoci  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version16.04.5 LTS
Product Version0.44.12 
Fixed 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 Informationhttp://dffd.bay12games.com/file.php?id=14084
TagsNo tags attached.

Relationships

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

Activities

Loci

2019-02-02 10:31

viewer   ~0039176

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):

http://dffd.bay12games.com/file.php?id=14225

Darxus

2019-02-21 05:28

reporter   ~0039231

My crash looks more related to this one, consistent segfault during save: 0011035

Darxus

2019-02-22 11:10

reporter   ~0039236

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

2019-02-22 22:17

reporter   ~0039237

Last edited: 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

2019-02-25 00:26

reporter   ~0039240

Last edited: 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

2020-01-29 00:37

administrator   ~0039686

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
2019-02-23 22:52 risusinf Note Edited: 0039237
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
2019-03-01 23:44 risusinf Note Edited: 0039240
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-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