Save/Load corruption bug for native Linux

[bryanperris]

How to reproduce:

1. Install the game from Steam on a Linux based system (Steam Deck for me)
2. Start a new game and make a save
3. Attempt to load the save, sometimes it will be fine.
4. If the game saves a bad save file, it crashes the game upon load.

[kevinbentley]

Can you verify that this bug still exists once the source has been compiled? We fixed a bunch of bugs that never made it into release. I'll try to find the list we had.

[bryanperris]

Do you have the official build instructions I should follow for Linux? Once its built, I can make a duplicate of the D3 Steam directory, and replace the binary executable with the GitHub version to test on the Steam Deck.

[bryanperris]

I think for my reported tickets, there should be a Steam label just to track, I found this issue from Steam version and not from this repo.

[JeodC]

I think for my reported tickets, there should be a Steam label just to track, I found this issue from Steam version and not from this repo.

If you can test and verify the bug exists in source, then leave it be. If it's not reproducible, close it. We should not be tracking steam version bugs.

[bryanperris]

Agreed, I meant more that the label to mark 'bug' issues not being related to this repo, I have no doubt others will also post here bugs they found on Steam D3 version.

[JeodC]

Author

I can see how that could cause confusion. Label created and applied.

[bryanperris]

This issue does exist.

I am playing level 1, saved a few times, used some cheats, save again.
Then I quit the game back to the main menu, then load my file.

So in the terminal a lot of these messages
RECOMPILE YOUR SCRIPTS!!!
Game-Checksum FAIL!!! (2273889867l!=2273873307l)
RECOMPILE YOUR SCRIPTS!!!
Game-Checksum FAIL!!! (2273889867l!=2273873307l)
RECOMPILE YOUR SCRIPTS!!!
Game-Checksum FAIL!!! (2273889867l!=2273873307l)
RECOMPILE YOUR SCRIPTS!!!
Game-Checksum FAIL!!! (2273889867l!=2273873307l)
RECOMPILE YOUR SCRIPTS!!!

Then what I caught in GDB:
Thread 1 "Descent3" received signal SIGSEGV, Segmentation fault. 0x000000000053ae1a in ObjUnlink (objnum=236) at /home/bperris/base/dev/Descent3/Descent3/object.cpp:1478 1478 seg->objects = obj->next;

Stacktrace
#2 0x000000000053ae1a in ObjUnlink (objnum=236) at /home/bperris/base/dev/Descent3/Descent3/object.cpp:1478 #3 0x000000000053c356 in ObjDelete (objnum=236) at /home/bperris/base/dev/Descent3/Descent3/object.cpp:1899 #4 0x00000000004cde11 in LGSObjects (fp=0x169a8f0, version=2) at /home/bperris/base/dev/Descent3/Descent3/loadstate.cpp:964 #5 0x00000000004cc06f in LoadGameState (pathname=0x7dabc0 <LGS_Path> "/home/bperris/Descent3/savegame/saveg000") at /home/bperris/base/dev/Descent3/Descent3/loadstate.cpp:343 #6 0x000000000048e73e in LoadCurrentSaveGame () at /home/bperris/base/dev/Descent3/Descent3/gamesave.cpp:700 #7 0x0000000000490f65 in GameSequencer () at /home/bperris/base/dev/Descent3/Descent3/gamesequence.cpp:1222 #8 0x0000000000471f3d in PlayGame () at /home/bperris/base/dev/Descent3/Descent3/game.cpp:814 #9 0x00000000004647be in MainLoop () at /home/bperris/base/dev/Descent3/Descent3/descent.cpp:598 #10 0x000000000046466e in Descent3 () at /home/bperris/base/dev/Descent3/Descent3/descent.cpp:553 #11 0x00000000005e6b37 in oeD3LnxApp::run (this=0x7fffffffd470) at /home/bperris/base/dev/Descent3/Descent3/lnxmain.cpp:237 #12 0x00000000005e6a6b in main (argc=1, argv=0x7fffffffd678) at /home/bperris/base/dev/Descent3/Descent3/lnxmain.cpp:737

[bryanperris]

@kevinbentley
I have applied this change to object.cpp line 1475:
terrain_segment *seg = &Terrain_seg[cellnum & 0xFFFF];

No more crash, my save file loads, ship restores to the right place, gameplay seems normal, I am not sure how to verify all the information without some kind of compare log between memory states. Poking you, if it make sense that cellnum should be wrapping around on the terrain table.

Edit: so I noticed the terrain segment isn't null, but has some non-zero memory address, then printed the cellnum value, and noticed it way beyond the table's memory range, so no longer it was crashing. I would like to investigate more on why the cellnum went beyond the range anyways.

I found the cellnum mask: #define ROOMNUM_CELLNUM_MASK 0x7fffffff
This signed 32-bit mask is way larger than 16 bits.

[JeodC]

@kevinbentley I have applied this change to object.cpp line 1475: terrain_segment *seg = &Terrain_seg[cellnum & 0xFFFF];

No more crash, my save file loads, ship restores to the right place, gameplay seems normal, I am not sure how to verify all the information without some kind of compare log between memory states. Poking you, if it make sense that cellnum should be wrapping around on the terrain table.

Edit: so I noticed the terrain segment isn't null, but has some non-zero memory address, then printed the cellnum value, and noticed it way beyond the table's memory range, so no longer it was crashing. I would like to investigate more on why the cellnum went beyond the range anyways.

I found the cellnum mask: #define ROOMNUM_CELLNUM_MASK 0x7fffffff This signed 32-bit mask is way larger than 16 bits.

Is this resolved or just partially resolved?

[bryanperris]

I don't feel it is resolved, only found a simple way to avoid the crash. It is going to take time to figure out a better solution since it doesn't affect Windows builds.

[bryanperris]

closer to the issue here:
when load routines reads in the objects, it is reading in a negative value

Read roomnum: -2147447883
Read roomnum: -2147447883

[bryanperris]

here is a dump of read room numbers from the object file
https://pastebin.com/p8qVPSJ9

[bryanperris]

I applied the 16-bit mask to all of the terrain cell calls, but I cannot open the first door in level 2 after loading my problematic save file.

[viggen66]

Can you share your compiled Descent3 binary with saved game fixed?

[bryanperris]

I have not fixed the issue but only prevent crashing with a hack, still investigating.