Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0011532Dwarf FortressTechnical -- Saving/Loadingpublic2020-04-29 10:292020-04-30 00:04
normalmajorhave not tried
0011532: Corrupted save: std vector length according to debugger
I saved the fortress using DFHack's quicksave. When that was done I killed DF with DFHack's die command and shut down the computer.
When I returned to continue playing DF crashed every time when loading the save. I disabled DFHack, and it still crashed. I hooked up a debugger to DF before starting to load the save both with and without DFHack enabled, and it still crashes with a debugger hooled up to it: "Exception Unhandled
Unhandled exception at 0x00007FF9F732A799 in Dwarf Fortress.exe: Microsoft C++ exception: std::length_error at memory location 0x00000064B70FF200".

The corrupted save has been uploaded to http://dffd.bay12games.com/file.php?id=15047 [^]
Using LNP r04, the Phoebus tileset, DFHack
- PSV world
- DFHacking all glaciers to evil during world gen
- Biodiversity DFHacking to assign all surface plants and creatures to all biomes they're legal for.
- Ensure a particular biome is evil.
- Pre embark DFHacking to shape the biomes at the embark to contain all the 9 biomes possible.
Raws slightly modded:
- Wood for woodless trees to get them to appear.
- Doubled Gremlin size to allow others to make Kobold clothes for it before it can petition and make clothes itself (which requires using Dwarf Therapist), as they'll go insane during the petition cool down otherwise.
- Reduced all attack triggers for monsters
- Reduced attack triggers for civs
- Made goblins start on glaciers exclusively
- Increased max site size for elves (in the hope of getting enough of them to visit)
- Removed mandates for dwarf nobility (I consider them incompatible with the injustice system that's mandatory with Villains).

During game play I've made liberal use of DFHack's "exterminate him" command to kill hordes of questers and villains to avoid the loyalty cascades and hidden aggressive visitors that happen frequently when attacking with militia. However, I think there had been a lull of some time since the last villain showed up when I saved.
No tags attached.
Issue History
2020-04-29 10:29PatrikLundellNew Issue
2020-04-29 20:15lethosorNote Added: 0040518
2020-04-29 20:16lethosorNote Edited: 0040518bug_revision_view_page.php?bugnote_id=0040518#r16462
2020-04-30 00:04PatrikLundellNote Added: 0040519

2020-04-29 20:15   
(edited on: 2020-04-29 20:16)
I was able to reproduce on Linux with the following backtrace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007ffff66ce859 in __GI_abort () at abort.c:79
0000002  0x00007ffff6ca0951 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
0000003  0x00007ffff6cac47c in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
0000004  0x00007ffff6cac4e7 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
0000005  0x00007ffff6cac799 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
0000006  0x00007ffff6ca3366 in std::__throw_length_error(char const*) ()
    at /lib/x86_64-linux-gnu/libstdc++.so.6
0000007  0x0000000000412cb3 in  ()
0000008  0x0000000000412d43 in  ()
0000009  0x000000000096c901 in  ()
0000010 0x0000000000f7067e in  ()
0000011 0x00000000011c9e68 in  ()
0000012 0x0000000000995c1e in  ()
0000013 0x00007ffff6e47eb2 in interfacest::loop() () at ~/DF/0.47.04/libs/libgraphics.so
0000014 0x0000000000a486ee in mainloop() ()
0000015 0x00007ffff6e2c1c5 in enablerst::async_loop() ()
    at ~/DF/0.47.04/libs/libgraphics.so
0000016 0x00007ffff6e2c4e0 in call_loop(void*) () at ~/DF/0.47.04/libs/libgraphics.so
0000017 0x00007ffff743cf3c in  () at /lib/x86_64-linux-gnu/libSDL-1.2.so.0
0000018 0x00007ffff747cbaf in  () at /lib/x86_64-linux-gnu/libSDL-1.2.so.0
0000019 0x00007ffff6613609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000020 0x00007ffff67cb103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

It looks like you're using uncompressed saves, so this is probably not a compression issue. I don't know if it's possible to recover the save from this, but maybe it will be useful in tracking down a possible save-corrupting bug (though I'm a bit hesitant to confirm this in case DFHack usage was the cause, even if it's unlikely in this case).

2020-04-30 00:04   
Thanks for looking at the save.

Yes, I'm using uncompressed saves because the compression time was rather significant when I tried it.

While I don't think it's caused by DFHack, I wanted to make clear that I use it to avoid confusion is case that's incorrect.