|Anonymous | Login | Signup for a new account||2023-04-01 10:27 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010939||Dwarf Fortress||Technical -- General||public||2018-10-24 15:42||2020-01-29 00:38|
|Platform||Linux||OS||Ubuntu||OS Version||16.04.5 LTS|
|Target Version||Fixed in Version||0.47.01|
|Summary||0010939: segfault on "Saving fortress information" when trying to save, reproducible via savestate|
|Description||Game 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|
* "Save Game"
|Additional Information||http://dffd.bay12games.com/file.php?id=14084 [^]|
|Tags||No tags attached.|
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):
|My crash looks more related to this one, consistent segfault during save: 0011035|
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?
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.
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.
Toady One (administrator)
|This one was similar to 0010742, but not the same - here the dancer had corrupt criminal data.|
|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|