Project

General

Profile

Bug #1846

[Hexen] Broken saves in the Heresiarch's Seminary hub

Added by JGondek over 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Regression
Target version:
Start date:
2014-07-20
% Done:

100%

Tags:

Description

I've experienced this bug when I was finishing the Heresiarch's Seminary hub.
The save I made just before the exit gate has turned out unloadable. When I try to load it, the game exits to the menu screen and the following text is displayed:

Load save game "? Press y or n

If I press y, the game crashes with the error:

Application terminated due to exception:
Uncaught exception during loop iteration:
[InProgressError] (GameSession::reloadMap) No game session is in progress

I attached the provided details.

If I press n, I can safely return to the main menu, hovewer any consecutive attempts to load some other save files crashes the game with a "Segmentation error".

This also applies to any further save files I make while playing the Castle of Grief hub.

That was yesterday. Today none of my saves work, all of them behave like broken. When I press y, the game crashes with a different error:

App init failed:
[InvalidIdError] (PersistentCanvasWindow::main) No window found with id "main"

I've seen this bug before while quick-saving (unfortunately with the 1.14.5 release).
I'm attaching the problematic save file.

I don't know if it's related, but dometimes when I launch Hexen, an error report appears - "savegametool.exe has stopped working". When I close it, the game loads successfully.

There seems to be a problem with attaching files in Redmine, so here are the uploads:
https://www.dropbox.com/s/4y1i96weampe1lc/hex2.save <- this doesn't work
https://www.dropbox.com/s/akpa20limb17wif/hex5.save <- this worked until today
https://www.dropbox.com/s/0550j0g6bdcrsyx/details_after_pressing_y.txt <- log

details_after_pressing_y.txt (16.9 KB) details_after_pressing_y.txt log JGondek, 2014-07-20 13:24
hex2.save (139 KB) hex2.save broken save file JGondek, 2014-07-20 13:24
hex1.save (139 KB) hex1.save JGondek, 2014-09-20 17:03

Related issues

Has duplicate Bug #1850: [Hexen] Possible savegame regression (golden doors closed on Seven Portals)Closed2014-08-06

Associated revisions

Revision 1cbb03ef (diff)
Added by danij over 9 years ago

Fixed|libcommon|ACS: ACS world state deserialization

Somewhere a superfluous 32-bit unsigned integer is being written to
the ACS world state data...

IssueID #1846

History

#1 Updated by danij over 10 years ago

  • Status changed from New to In Progress
  • Assignee set to danij

#2 Updated by JGondek over 10 years ago

Reinstall of Doomsday Engine fixed the load of all the saves that have been working before. "hex2.save" is still broken.

#3 Updated by danij over 10 years ago

  • Has duplicate Bug #1850: [Hexen] Possible savegame regression (golden doors closed on Seven Portals) added

#4 Updated by skyjake over 10 years ago

  • Target version set to 1.15

#5 Updated by JGondek about 10 years ago

I found out that the bug is probably map-independent and is caused by erroneous behaviour of the saving mechanism. It is related to the number of consecutive saves and loads (some parameter keeps incrementing and eventually overflows). You can easily see this in the file I attached - to reproduce the bug, save and load the game a few times in a row. I hope you will manage to fix it as it breaks the game. Thank you.

#6 Updated by danij about 10 years ago

We are aware of the cause of this bug however we haven't gotten around to implementing a suitable fix yet. It will definitely be resolved for the 1.15 release.

#7 Updated by skyjake almost 10 years ago

  • Assignee changed from danij to skyjake

#8 Updated by danij almost 10 years ago

  • Assignee changed from skyjake to danij

#9 Updated by danij almost 10 years ago

details_after_pressing_y.txt:

Error loading from save slot #2: [OffsetError] (Block::get) Out of range (268[+4] > 268)

This nugget of info is very telling. Sadly, I'd already determined this after a several hours of debugging. Shame that nobody who encountered this issue in the flesh (so to speak) previously had thought to provide their log file else it might have been addressed before now.

#10 Updated by danij almost 10 years ago

  • % Done changed from 0 to 40

#11 Updated by danij almost 10 years ago

  • % Done changed from 40 to 90

#12 Updated by danij over 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

#13 Updated by skyjake over 9 years ago

  • Tags set to Hexen, SaveGame

This savegame code (readWorldState) is using the libcore Reader/Writer classes? Methods that write an "extra" 4-byte value include withHeader() and variable-length buffer/string methods. I wonder if there is some discrepancy there between the writing/reading code.

Thinking long term, any discrepancies could be avoided by adopting a more abstracted system that describes the data in terms of data fields, where the reading and writing is done automatically the same way by the lower-level objects. In practice, this could be achieved by serializing Records instead of writing C-struct-like data. Serialized Records would also offer better robustness when the saved data changes from one version to another.

#14 Updated by danij over 9 years ago

skyjake wrote:

This savegame code (readWorldState) is using the libcore Reader/Writer classes? Methods that write an "extra" 4-byte value include withHeader() and variable-length buffer/string methods. I wonder if there is some discrepancy there between the writing/reading code.

Yeah, this code does use libcore's Reader/Writer. More than likely this is indeed a read/write discrepancy but looking at the code nothing immediately stands out and at least appears to be symmetrical.

Also available in: Atom PDF