Save load crash investigations

[Flocke]

Hey there, while testing some assembler hooks, I came across the 0x000b6c66 fault offset crash again and managed to reproduce this to have a closer look.

One other crash I get every other savegame load is:

Code: Select all

trek.exe 0x000b6c66

This one sometimes even shows up when I solely keep loading unmodified vanilla games. But with modified files it often becomes more frequent. With some games it repeatedly already shows up each second time I load the save. Then when I have rebooted it becomes less frequent again. Therefore my guess is that it is related to some dead memory references, e.g. some array index like a system index that I missed to update. But since it also happens on vanilla games it might also be just random bad luck.

It's sub_4B77E0 race_rst_start_set_races_in_game_via_RToSInfo -> updated races in game bitmask for race IDs 32+ -> loaded [gameInfo+274h]

A strange code also related to the readrace crashes during galaxy generation. Shouldn't be used for loaded games, but there is some odd x-ref calls.

Since it also happens with unmodded vanilla trek.exe it can't be outdated/flawed patches in that subroutine?

First of, other than I assumed in viewtopic.php?p=41435#p41435 the fault offset does not refer to the file offset, but to the loaded application base offset. Which often enough happens to be same, but not this case. Relative to base offset 400000h it actually crashed at asm offset 0x4B6C66.

Having the debugger attached I found why:

Screenshot 2026-07-17 065407.png

Screenshot 2026-07-17 065726.png

Here you see ecx has become a negative value, which messes up the copied data offset.

With further analysis I found that by the chop call at asm 418E32 a double of 0 gets rounded to -5 = 0xFFFFFFFB!!

Screenshot 2026-07-17 104502.png

By the Universe_Sector_GetSectorPos call at asm 418EE3 the eax register, read back from [esp+24h+var_C] at asm 418E3B, is used as the map sector index, and of course the map starts at index 0 and not in the negative range!

If we leave out the chop call, it might be fixed I guess, but due to precision limitations, it often makes sense to round floating points to upper or lower nearest integer before conversion to exactly prevent issues like this - well if only the rounding worked...

The full callstack I deduced as follows:

Code: Select all

418EE3         call    Universe_Sector_GetSectorPos
42B5A1         call    AI_AIPatrol_418E00
419197         call    AI_AIMilEvl_42B4F0
41AD33         call    dword ptr [edx+10h]
4E7875         call    AI_AIColony_41AD30
4DD207         call    UI_MainGal_MapAI_4E7750
4D9EE2         call    UI_MainGal_GalMap_Initialize
4B8F80         call    [ebp+UIDsc_ScreenDescriptor_t.func_InitScreen]
4B9468         call    UI_Screens_LoadScreen
4F00EA         call    UI_Screens_Init2
4F0925         call    UI_LoadSave_LSScreen_LoadOrSave
52D151         call    [ecx+UIWgt_PushButton_t.clickCallback]
52CD9E         call    PushBtn_OnLMB_Up
53D6DC         call    [ecx+UI_Widget_t.eventHandler]
513235         call    Widget_HandleMouseInput
512CD4         call    Graphics_HandleMouseInput
401642         call    Graphics_HandleUserInput

[Flocke]

Since we have a file attachment limitation, here two Vanilla 1.0.4 savegames to reproduce this issue:

game8.sav

game11.sav

First load game8.sav, then game11.sav and then game8.sav again and for me it (for now) reliably crashes with above error.

[Spocks-cuddly-tribble]

Yeah, this mess looks like a bug.

418E4E         jnz     loc_418EDD  // eax is never a sector index in this case

Not sure if just nop works here or more edits are required.

[Flocke]

Not sure if just nop works here or more edits are required.

And I hoped that you would give me a suggestion how to fix this mess!