Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0006463Dwarf FortressTechnical -- Saving/Loadingpublic2014-03-30 13:562014-07-14 11:35
PC running on MAC using VMwareXPlast update
0006463: Crash on save, does not save
Anytime I save, DF auto saves seasonally (as set through LNP v.15), or I quick save through DFhack it crashes. I never get to the cleaning objects screen. Nothing is saved when I reopen.
save, auto save, or quick save
This is a fortress I lost and reclaimed, and have successfully played for 6.5 in game years over the past month or so.

I have reinstalled LNP and have the same error. I started a new game on another map to see if I would get the same error and I did not. Have played many other fortresses on this computer for over a year without a problem like this before.

I have had a few other inconsequential crashes recently - a couple where DF crashed during the cleaning objects phase of a save but the save still worked, and Dwarf Therapist (v. 0.6.12, branch v.20.4) has crashed a couple times lately and that had never happened before.
crash, saving
related to 0001371resolved Dwarfu "Nemesis Unit Load Failed" (from elves?) 
Issue History
2014-03-30 13:56animate_meNew Issue
2014-03-30 14:04animate_meIssue Monitored: animate_me
2014-03-30 14:05animate_meTag Attached: crash
2014-03-30 14:05animate_meTag Attached: saving
2014-03-31 21:16FootkerchiefNote Added: 0024662
2014-03-31 21:16FootkerchiefStatusnew => resolved
2014-03-31 21:16FootkerchiefResolutionopen => no change required
2014-03-31 21:16FootkerchiefAssigned To => Footkerchief
2014-04-02 15:41animate_meNote Added: 0024665
2014-04-02 15:41animate_meStatusresolved => needs feedback
2014-04-02 15:41animate_meResolutionno change required => reopened
2014-04-02 16:18FootkerchiefNote Added: 0024666
2014-04-02 16:18FootkerchiefStatusneeds feedback => resolved
2014-04-02 16:18FootkerchiefResolutionreopened => unable to reproduce
2014-04-02 18:20animate_meNote Added: 0024667
2014-04-02 18:20animate_meStatusresolved => needs feedback
2014-04-02 18:20animate_meResolutionunable to reproduce => reopened
2014-04-03 03:13agNote Added: 0024668
2014-04-03 03:14agIssue Monitored: ag
2014-04-03 05:46QuietustNote Added: 0024669
2014-04-03 05:49QuietustNote Edited: 0024669bug_revision_view_page.php?bugnote_id=0024669#r9220
2014-04-03 05:49QuietustNote Edited: 0024669bug_revision_view_page.php?bugnote_id=0024669#r9221
2014-04-03 05:58QuietustNote Edited: 0024669bug_revision_view_page.php?bugnote_id=0024669#r9222
2014-04-03 05:59QuietustNote Edited: 0024669bug_revision_view_page.php?bugnote_id=0024669#r9223
2014-04-11 15:56animate_meNote Added: 0024682
2014-04-11 15:56animate_meStatusneeds feedback => assigned
2014-04-11 17:30QuietustNote Added: 0024683
2014-04-12 18:44animate_meNote Added: 0024685
2014-04-12 20:34QuietustNote Edited: 0024683bug_revision_view_page.php?bugnote_id=0024683#r9227
2014-04-12 20:34QuietustNote Edited: 0024683bug_revision_view_page.php?bugnote_id=0024683#r9228
2014-04-12 20:36QuietustNote Added: 0024686
2014-04-13 10:33animate_meNote Added: 0024687
2014-04-13 20:56FootkerchiefNote Added: 0024690
2014-07-14 11:35FootkerchiefRelationship addedrelated to 0001371

2014-03-31 21:16   
Please reopen this if you can reproduce the problem in a save that's never been messed with via DFHack. Unless that can be ruled out, it's not worth the effort for Toady to track it down.
2014-04-02 15:41   
I never used DFhack before I had the save problem. The only thing I did in DFhack was try and quick save when the other save methods caused a crash.
2014-04-02 16:18   
We still need the save. Please upload it to http://dffd.wimbli.com/ [^] and post the link here.
2014-04-02 18:20   
Ok - I think I uploaded what you need:
http://dffd.wimbli.com/file.php?id=8505 [^]
2014-04-03 03:13   
It seems you somehow got one of the flag arrays in the nemesis data structures messed up: it has nonzero length value, but the memory is not allocated. Try this dfhack command:

:lua df.global.world.nemesis.all[17368].flags:resize(1)

I think the most likely way it can become this way immediately after load is that the array is set to nonzero length by the constructor of the object, but in the original save file it is stored as zero length. From the code in g_src, it looks like in that case read_file would reset array to NULL, but not clear slotnum. Of course, another question is why it is saved as zero length in the file...
2014-04-03 05:46   
(edited on: 2014-04-03 05:59)
The nemesis entry itself appears to be totally corrupted - the nemesis ID is 16843009 (0x01010101), the unit ID is only 257 (0x00000101), the unit chunk id/slot values are both zero, and the other values are also nonsense.

2014-04-11 15:56   
ag - Thanks for trying to help. I tried that dfhack command but got the error:
"Error: cannot open df.global.world.nemesis.all[17368].flags:resize(1) no such file or directory
stack traceback:"

I've never looked at the save files before. What files are you looking at and what program are you using to look at them?
2014-04-11 17:30   
(edited on: 2014-04-12 20:34)
A possibly better fix would be to type "lua" followed by "df.global.world.nemesis.all:erase(17368)" (and then "quit").

[edit] missed the ".all"

2014-04-12 18:44   
quietust - thanks for the suggestion but that dfhack command didn't work either. I got the same error as before.

Any other thoughts? Is there maybe something different about my set up that would do this?
2014-04-12 20:36   
If you're getting the same error, then you didn't run the command properly - when you type "lua", you should get a "[lua]#" prompt, and that's where you need to type the second command (note that I just corrected a typo in it) once you've loaded your game (and then "quit" to bring you back to the "[DFHack]#" prompt).
2014-04-13 10:33   
That totally worked!!! Thank you so much!
2014-04-13 20:56   
Any possible relationship between this bug and 0001371?