Author Topic: Evacuation Under Fire - Ply Campaign Scenario  (Read 44669 times)

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #25 on: June 15, 2018, 12:11:59 PM »
I'm impressed at how it's possible to analyze so much of the OP2 internals without having access to the OP2 source code. Good luck with hunting down this problem the rest of the way.

Is there something different between the player loading a unit into the garage or a unit already being loaded at the beginning of the scenario that causes only the latter to be vulnerable to corruption?

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #26 on: June 19, 2018, 08:28:18 PM »
Should be no difference in regards to loading vehicles into a garage at the start of the level versus during game play. In terms of how the DLL interfaces with the game, the vehicle is actually created outside the garage first, and then loaded into it.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #27 on: June 08, 2019, 11:21:22 PM »
I posted a new version of the mission and moved the downloads to the Github release page. See the first post for the new location of the downloads.

The new version properly sets HFLInit in DLLMain. In previous versions, HFLInit would not be initialized when loading a game, only when the game is first started. I'm not sure if this could affect the garage bug.

With the new version, old saved games will still exhibit the garage bug if they are present previously.

I tried saving/loading a half dozen times and was unable to reproduce the bug. Don't know if HFL being present changed anything or if I was just lucky and didn't encounter the bug. Not sure HFL even plays in this bug at all.

-Brett

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #28 on: July 18, 2019, 11:12:27 PM »
It took me a few tries, but with v1.0.1 off of github I managed to duplicate the garage bug (see dump below).

I have played around some more to see if I can find a way to reliably reproduce it. The steps are to start a new mission, save twice, and then click on a garage and press S. Saving only once never works, and more than twice doesn't help if twice wasn't enough. Loading is not necessary.

If Outpost has been closed for more than 5 minutes when I start it, and I immediately try to trigger the bug, the bug will happen. If Outpost crashed due to this bug, restarting Outpost and immediately trying the bug will always succeed. However if Outpost has been running normally for a while, the bug will usually not happen, even if I close and restarting Outpost.

I continue to think there is something funny going on in my system to explain this behavior.

I've attached two saves, which were made immediately after each other. In SGAME2 the bug does not happen, in SGAME3 it does. (Normal difficulty.)

Code: [Select]
Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x004634cb).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:004634cb ESP:0034f9e0 EBP:04261c50 EFLAGS:00010202(  R- --  I   - - - )
 EAX:00000001 EBX:00000000 ECX:04261cc8 EDX:00456ce0
 ESI:00565d30 EDI:005663d4
Stack dump:
0x0034f9e0:  00000000 00565d30 00565d30 004d4fb0
0x0034f9f0:  00565d34 00000001 00456ce0 00565690
0x0034fa00:  04261cb0 0056d250 ffffffff 0047efb9
0x0034fa10:  0047efb9 04a04978 ffff0000 00000000
0x0034fa20:  0049d244 00000000 00577ee8 59960000
0x0034fa30:  00570010 00463153 00575d18 0045d1f7
Backtrace:
=>0 0x004634cb EntryPoint+0xffffffff() in outpost2 (0x04261c50)
  1 0x04265850 (0x004cfca0)
  2 0x0043ada0 EntryPoint+0xffffffff() in outpost2 (0x0041d630)
0x004634cb EntryPoint+0xffffffff in outpost2: call *0x0(%eax)
Modules:
Module Address Debug info Name (40 modules)
PE   370000-  3e0000 Deferred        out2res
PE   400000-  5bc000 Export          outpost2
PE 10000000-10011000 Deferred        op2ext
PE 11000000-1102d000 Deferred        c_euf
PE 20000000-2001a000 Deferred        odasl
PE 7b430000-7b5ed000 Deferred        kernel32
PE 7bc30000-7bc34000 Deferred        ntdll
PE 7cde0000-7cde4000 Deferred        dsound
PE 7d120000-7d123000 Deferred        winealsa
PE 7d160000-7d164000 Deferred        mmdevapi
PE 7d2f0000-7d2f8000 Deferred        oleaut32
PE 7d520000-7d523000 Deferred        api-ms-win-core-localization-l1-2-1
PE 7d550000-7d553000 Deferred        api-ms-win-core-fibers-l1-1-1
PE 7d590000-7d593000 Deferred        api-ms-win-core-synch-l1-2-0
PE 7d6c0000-7d6c3000 Deferred        msvcr120
PE 7d7b0000-7d7b4000 Deferred        uxtheme
PE 7d9d0000-7d9d3000 Deferred        concrt140
PE 7da10000-7da14000 Deferred        winex11
PE 7dce0000-7dce3000 Deferred        api-ms-win-crt-heap-l1-1-0
PE 7dcf0000-7dcf3000 Deferred        api-ms-win-crt-stdio-l1-1-0
PE 7dd10000-7dd13000 Deferred        api-ms-win-crt-string-l1-1-0
PE 7dd20000-7dd23000 Deferred        api-ms-win-crt-runtime-l1-1-0
PE 7dd30000-7dd33000 Deferred        vcruntime140
PE 7dd80000-7dd84000 Deferred        ucrtbase
PE 7de90000-7de94000 Deferred        msvcrt
PE 7df90000-7df93000 Deferred        msvcp140
PE 7e080000-7e084000 Deferred        iphlpapi
PE 7e0b0000-7e0b4000 Deferred        ws2_32
PE 7e0e0000-7e0e4000 Deferred        wsock32
PE 7e100000-7e104000 Deferred        imm32
PE 7e130000-7e133000 Deferred        usp10
PE 7e1b0000-7e203000 Deferred        comctl32
PE 7e300000-7e309000 Deferred        msacm32
PE 7e340000-7e3bd000 Deferred        winmm
PE 7e430000-7e434000 Deferred        rpcrt4
PE 7e4f0000-7e518000 Deferred        ole32
PE 7e650000-7e654000 Deferred        advapi32
PE 7e6f0000-7e6f7000 Deferred        gdi32
PE 7e850000-7e950000 Deferred        user32
PE 7efe0000-7efe4000 Deferred        version
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Z:\home\user\games\outpost2\test\137\Outpost2.exe
00000036   15
0000002d   15
0000002c    0
0000002b    0
00000009    0 <==
0000000e services.exe
00000021    0
0000001a    0
00000013    0
00000010    0
0000000f    0
00000011 plugplay.exe
00000017    0
00000016    0
00000012    0
00000018 winedevice.exe
0000001c    0
0000001b    0
00000019    0
0000001d explorer.exe
00000027    0
00000026    0
00000025    0
0000001e    0
0000001f winedevice.exe
00000024    0
00000023    0
00000022    0
00000020    0
System information:
    Wine build: wine-4.9
    Platform: i386
    Version: Windows 7
    Host system: Linux
    Host version: 4.20.4-gentoo

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #29 on: July 25, 2019, 09:13:17 PM »
pente,

Thank you for retesting and the detailed debug data. I've left the bug as outstanding in the upcoming Outpost 2 release. Unfortunately, I'm not sure that I have the skills to debug on my own.

-Brett

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #30 on: July 27, 2019, 11:52:18 AM »
I am mighty curious what is causing this bug, but so long as I'm the only person who's ever run into it I don't think anyone should be losing any sleep over it -- I've beaten this mission enough times that this bug is no concern to me. Still probably my favorite Outpost 2 mission though!

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #31 on: July 28, 2019, 07:07:08 PM »
I've managed to reproduce the bug independently in the past, although not nearly as reliably as you have. So not just limited to your computer. I think maybe most people don't bother to report it or are not saving until after they deal with the garage contents.

Thanks for the compliment on the mission. I may pick up work on Mesa Missions again in the near future, the next mission in the series.

-Brett

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #32 on: August 19, 2019, 11:27:43 PM »
I took a look at the new saved game files. I haven't really found much in terms of a cause, other than what we already know.

The garage I clicked on had 3 units inside. The bay section of the Garage unit had 3 valid looking pointers to 3 unit records. Each of those 3 unit records had the virtual function table pointer replaced with the unit type index (enum mapId). It's standard practice for the game to replace the virtual function table pointer of each unit with the corresponding mapId value when saving, and then restore it afterwards (to continue playing after saving), or when loading. As to why it's not being properly replaced with the virtual function table pointer, I don't know.

The double save requirement to reproduce this bug seems interesting. I wonder if that might be related to the translation done during save/load. It seems a little too suspect.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #33 on: August 21, 2019, 01:26:59 PM »
Was there any difference between the two save files? I saved them as quickly after each other as I could press the button, so they should be almost the same game state, except that one is broken and one not. I didn't get the two saves on the same tick, so it's not as easy as looking at a hexdump and seeing which bytes changed (I checked just in case :) ) but maybe you have a more sophisticated means of analysis.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #34 on: August 25, 2019, 02:11:26 AM »
Hmm, interesting thought. It made me realize we don't really have the tools to do a proper saved game file compare. I tried just opening them in a hex editor, but the two files are different sizes, and show a lot of differences right from after the initial header. We do have code to load and parse the map data into memory, but not the saved game specific data, such as unit data where the problem lies along with any likely clues. Even if we did though, we don't have any code that would compare them with each other. It would all need to be written.

With that said, the in-memory analysis has already determined which field has gone bad, so I'm not sure a comparison of the saved game data would give additional information. We already know which field, we just don't know why that field went bad.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #35 on: August 25, 2019, 01:24:50 PM »
I spent some time on this with OllyDbg. Unfortunately I'd forgotten much of what I'd already posted on June 10th in this thread, and so mostly just reconfirmed it.

The bug appears when a garage stored unit has it's next pointer set to -1. This is generally a marker of an unused unit record. When the game is loaded, some patch up code is run to convert certain index fields back to pointers, as well as converting the unit type to a virtual function pointer. This patch up code skips over unit records that have a next pointer set to -1. This means units with a next pointer of -1 won't have a proper virtual function table pointer set. If any virtual method calls are made for that unit, the game will crash. Normally this is fine, as unit records with a next pointer of -1 are supposed to be unused, and so should never have any virtual methods called on them.

In the case of the garage bug, the stored units have their next pointer set to -1, yet the garage still references them. Hence there are referenced unit records which have been marked as unused, and have no valid virtual function table pointer set. When you view the contents of the garage, it attempts to call a virtual method on the stored units. The virtual method is to get a pointer to unit type information, so it can extract the name of the unit type for display purposes.

In the crashing saved game (saved_twice), the stored units have their next pointer set to -1. In the good saved game (saved_once), the stored units have a valid next pointer set.



Methods of interest:
Code: [Select]
00435CD0  Function: Map.UnitIndexesToPtrs()  [[vtbl] and [next, prev, playerNext]]
0041CF40  Function: Unit:Building:Garage.OnLoad()
004632B0  Function: CommandPaneView:BuildingStorageBays.???()  [DrawStorageBayPane]



It hasn't been observed how the stored unit records are marked as unused. There is however a bug in the code relating to some unique garage behavior.

When a unit is stored in a garage, the next pointer is set to -2. The game has lots of sentinel value checks for -1, but none for -2. Normally, if the field is not -1, it is expected to be a valid pointer to another unit record. In particular, the patch up code tries to convert pointers to indexes for all next pointers not set to -1. This calculation is not valid for the value -2, and so this corrupts the field when saving. The reverse conversion will also produce an unexpected and corrupted value.

It's not known if this corruption leads to further problems, or if it somehow gets corrected. In particular, I suspect the next pointer field would be restored to a proper value when a unit is unloaded from the garage. The field should remain largely unused while the unit remains in the garage, so the corrupted value may not be noticeable.



Given that this bug has only presented for this one level, and given that it does so consistently, there's likely something level specific that triggers this behavior. It may be caused in part by the corrupted next pointer field, or it may be caused through some other means. In particular, the garage stored units that end up with a next pointer field of -1 also have their flags field set to indicate an unused or dead unit. This suggests there may be some other mechanism involved that sets both the next pointer field and the flags field to indicate an unused unit record.

The problem may or may not relate to the corruption from the general bug, and most likely to something level specific. It's unlikely the problem -1 value would come from corruption alone.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #36 on: August 26, 2019, 07:27:49 PM »
Thanks for taking so much time on this issue again. I had been hoping that, since it takes two saves for the crash to occur, there would be some form of visible corruption in the first save (as after all, *something* must go wrong in the first save to put it into a state where the second save corrupts it), but I appreciate your point about the difficulty of doing that kind of analysis.

I guess we'll just have to remain in the dark about this bug until one of these Outpost remake projects gets far enough along that we have a playable successor game. And hopefully they don't replicate this particular bug :D

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #37 on: August 27, 2019, 02:45:11 PM »
I would actually like to keep working on this. My current problem though is that I'm unable to reproduce the problem on my own. Your saved game exhibits the crash, which provided the info for the initial investigation. It doesn't quite tell how the unit data got corrupted or units got killed within the garage though. So far I've been unable to reproduce the transition from good unit data stored in garages to bad unit data stored in garages. If I could reliably reproduce that, there would be more I could determine.

I've tried restarting the level and saving twice multiple times, and then checking the garage, but so far no problems. I've tried restarting from within the level, from going back to the main menu, and from restarting Outpost 2. I also tried loaded up the bad save to get a crash first, then reloading the game and trying again. Nothing seems to cause problems with the garage. I'm not sure how often the problem occurs, though I probably tried maybe a couple dozen times.

Is there anything more you can determine about reproducing the problem from a good state? How often does it fail?

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #38 on: August 28, 2019, 06:37:53 AM »
Hooman, if you are interested, we can pair program and use my machine to reproduce the bug more reliably. I would generally be available this Monday at the earliest.

Thanks,
Brett

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #39 on: August 28, 2019, 02:13:08 PM »
That would be quite helpful. I was becoming increasingly tempted to start giving pente instructions on how to use the OllyDbg debugger. ;)  (The offer still stands) :P

I plan to be busy Monday, though if it's done early, or late, I may be able to sneak it in.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #40 on: August 29, 2019, 12:18:07 PM »
How about next Friday after 6pm Eastern or Saturday from 8am to 10pm Eastern?

If you have a reference for me to read on beforehand, it might save some explaining. As all I remember from our last session is EAX means something about copying a variable... I was trying to load the udd file into ollydbg the other day and couldn't figure it out although I didn't try too hard. I think you may have posted how to do it on the forum somewhere. I should look that up beforehand.

Happy if pente wants to join or if you two want to work without me. There are plenty of things to do.

Thanks,
Brett

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #41 on: September 01, 2019, 04:17:55 AM »
It looks like OllyDbg is a windows program? I'd be happy to try out any experiments you want if you can give me step-by-step instructions that work on linux.

I don't expect to be available for live debugging but if I remember I'll check back here on the forum before Friday.

I haven't done anything of substance with assembly since 2005 so I'm going to be struggling to understand any disassembled output.

The bug seems to be pretty consistent (>75% ?) under the conditions I described above. However it does seem to be sensitive to how long it's been between closing Outpost 2 and starting it, which makes trying to trigger the bug an unnerving process.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #42 on: September 01, 2019, 10:12:43 AM »
OllyDbg works just fine on Linux under Wine. That's how I use it these days.

If you want to try it out, I highly recommend downloading the OllyDbg comments file for the Outpost 2 executable. It contains years of reverse engineering comments and code labels. You can find Outpost2.udd at:
https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/OllyDbg
(The site's certificate may be out of date, so the browser may show a warning about an insecure connection)

Important OllyDbg settings:
Options -> Appearance -> Directories : UDD Path    (Copy Outpost2.udd to this folder)
Options -> Debugging Options -> Security :
  Ignore path and extension
  Ignore timestamp
  Ignore CRC of code section
Check those boxes, or OllyDbg may ignore the .udd file and then overwrite it with a fresh analysis.

To check if the comments file has been loaded, open the Names window (shortcut: Ctrl+n), and look for entries with Type set to User. These are the user defined labels we set while reverse engineering. There should be about 4500+ user defined labels. If the comments file was not loaded, you'll only see the imports and exports (about 750+).



@Brett: The MOV command copies a value. Values can be stored in registers, such as EAX. :P

I'm afraid I don't have much in the way of a reference to point people to, though perhaps I should prepare something.

I may be free on Monday after all. I won't be free on Friday. Leaving early to go camping for the weekend.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #43 on: September 01, 2019, 06:22:52 PM »
Hooman, Pente,

It took me about a 18 tries, but Outpost 2 finally crashed. Just like pente described, if I save twice in a row and then go to garage and press 's', it will eventually crash. Not sure why it is so much more prevelant in the Linux/Wine combo than Win 10, but it is not isolated to one machine or operating system.

Hooman,

I can be available at 7PM Eastern time tomorrow (2 SEP) for about 2.5 hours if that works for you. Since I thought you were busy, I made plans earlier in the day to do some pair programming on a multiplayer mission. Hopefully my brain isn't jelly by the end of the earlier session. :)

If you are good with it and available, primary Team Viewer, secondary Discord for screen sharing / audio. I'll jump into the chat room prior, but feel free to poke me on Team Viewer chat as well.

I found an undergraduate book on x86 assembly programming / debugging that I started reading through the intro. Probably not far enough in to be of practical help at this point but maybe in the future? I've got ollydbg and HxD already on my CPU. Also, ollydbg is successfully loading the .udd comments, so first step accomplished!

Hopefully we can get it to crash eventually and it doesn't take more than 18 times. The good news is, it is fairly quick to attempt crashing.

-Brett

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #44 on: September 02, 2019, 01:40:41 PM »
I will be available at that time.

I've got Team Viewer and Discord working on my old desktop. I'm having trouble finding a decent microphone that works, so the audio quality might suffer a bit. Still working on some options.

The amount of assembly knowledge required should be fairly minimal. The compiler mostly generates the same few instructions, so it's easy to learn the bulk of it quite quickly. Plus the best way to learn is often to be exposed to it.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #45 on: September 02, 2019, 05:02:23 PM »
I cannot join today.

I did try OllyDbg and was able to run Outpost 2 with it. I'm not sure what you had in mind to do, so I tried to duplicate the crash and see if anything interesting would happen.

I was unable to cause the crash from within OllyDbg. I repeatedly alternated between using OllyDbg and running Outpost 2 directly, and was able to trigger the bug every time from Outpost 2 directly, and never from within OllyDbg. This makes one suspect some kind of race condition, but there are other possible explanations of course.

Also when using OllyDbg, I got an error message when launching Outpost 2 before the menu comes up:

"Bad or unknown format of 32-bit executable file 'C:\windows\system32\oleaut32.dll'"

I did not get that message when running Outpost 2 directly.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #46 on: September 02, 2019, 05:15:39 PM »
Well, I am unexpectedly freed up and expect to have time to join for at least a little bit at the suggested time. Let me know the best way to get in contact with you and I'll see if I can do so.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #47 on: September 02, 2019, 10:17:24 PM »
Ahh gee, I didn't see your post until after we finished.

So the OllyDbg session went well. We were able to reproduce the bug while watching things unfold with OllyDbg. We spent a bit of time on initial setup getting the values we needed, and setting breakpoints at reasonable places. Brett did a quick run without OllyDbg to see if the bug could be reproduced by restarting the level, without having to go through the main menu, as that would save us quite a bit of time. After about 15-20 tries we found that was indeed possible. We then got setup in OllyDbg, and repeated the process. As the unit array potentially moved around each time the level was restarted, we found we had to clear and reset the hardware breakpoint on the field we were watching each round. This was a very tedious process. Brett managed to successfully reproduce the bug under OllyDbg after about 15-20 rounds. We kind of noticed something peculiar was up slightly before we witnessed what we were looking for. The next pointer on the unit record of a vehicle in a garage was first unexpectedly cleared to 0, and then shortly after was set to the -1 value we were looking for. As expected, the game crashed when we examined the garage contents after this.

The two writes before the crash were done in Map.UnitIndexToPtrs() and Map.SaveUnits. These were both functions that had been previously analysed, and were responsible for the translation between unit indexes and unit pointers during saving/loading. It was also related to the corruption of the value mentioned in earlier posts. Units have their next pointer set to -2 when loaded into a garage. This -2 value is not handled correctly by the conversion done during saving/loading. With a bit of luck, this corruption can lead the value to be converted back to 0. Normally a value of -1 is special cased to map to 0, and no valid value should map to 0. This means that during the reverse process, the 0 is special cased and maps to -1. Hence the -2 value is corrupted, and then converted 0, which is then mapped to -1, which indicates a dead unit, and so the game stops mapping the unit type back to a virtual function table, which leads to the crash.

To exhibit this bug, the -2 value must be corrupted in such a way that the reverse process maps the corrupted value back to 0. For this to happen, it depends on the address of the unit array. Each time the level is run, the unit array is reallocated, and may move around in memory. Certain addresses will trigger corruption in a way that the value gets mapped to 0. Hence the bug does not always exhibit itself every run.

This confirms the bug comes directly from the conversion process of the -2 value. There are no other factors at play here. This also shows the bug is in the game itself, and not part of the level. Any level with a garage, with units loaded into it, which is saved twice, runs the risk of corrupting the unit records of the stored units, and whether or not this happens depends on where in memory the unit array happened to be allocated.

The good news is, we can patch this. It shouldn't be too hard to write a replacement function that includes special casing for the -2 value as well as the -1 value. That should stop the corruption from happening during saving/loading. It won't fix already corrupted saved games, but it should prevent the problem from happening again. Perhaps we can roll something out in the next update of Outpost 2.




I may post further details later on about the exact sequence of events and values, and sample problem memory locations for the unit array. For now though, I'll leave the addresses of the two final writes that lead to values of 0 and -1 in the next field.

In Map.UnitIndexesToPtrs() the value 0 is unexpectedly stored at:
Code: [Select]
00435D34  MOV DWORD PTR SS:[EBP],EAX    ;  unit.ptr[j]* = [Unit*]nextUnit

In Map.SaveUnits(StreamIO* savedGameFile) the value -1 is stored at:
Code: [Select]
00435BC9  MOV DWORD PTR DS:[EDI],-1    ;  Unit.ptr[j] = -1


Of particular note, is how unexpected the write of 0 was. The larger code sequence is:
Code: [Select]
00435D1B  |/MOV EAX,DWORD PTR SS:[EBP]                  ;  EAX = [Unit*]currentUnit.ptr[j]*
00435D1E  ||CMP EAX,-1                                  ;  Check if ([Unit*]ptr == -1)  [IsDead]
00435D21  ||JE SHORT Outpost2.00435D39                  ;  -> Set unit.next* = 0
00435D23  ||SHL EAX,3                                   ;  [EAX = unitIndex * 8]
00435D26  ||LEA EDX,DWORD PTR DS:[EAX+EAX*2]            ;  [EDX = unitIndex * 24]
00435D29  ||LEA EAX,DWORD PTR DS:[EDX+EDX*4]            ;  [EAX = unitIndex * 120]
00435D2C  ||MOV EDX,DWORD PTR DS:[<Map.unitArray[]*>]   ;  EDX = Map.unitArray[]*
00435D32  ||ADD EAX,EDX                                 ;  EAX = &unitArray[unitIndex]
00435D34  ||MOV DWORD PTR SS:[EBP],EAX                  ;  unit.ptr[j]* = [Unit*]nextUnit
00435D37  ||JMP SHORT Outpost2.00435D40                 ;  -> Skip instruction
00435D39  ||MOV DWORD PTR SS:[EBP],0                    ;  unit.ptr[j]* = 0  [null]
00435D40  ||ADD EBP,4                                   ;  EBP = &ptr[j+1]
00435D43  ||DEC ECX                                     ;  numPtr--
00435D44  |\JNZ SHORT Outpost2.00435D1B

The bad write of 0 occurs at 00435D34. This is a calculated 0 value. It occurs when the corrupted field value is such that &Map.unitArray[corruptedIndex] == 0. For that to happen, we must have corruptedIndex * 120 = -&Map.unitArray, which is a rather bizarre thing to have happen. (Here sizeof(Unit) == 120). This is in contrast to the special cased write of 0 that would normally happen at 00435D39, which happens when an index value of -1 is converted to a nullptr.


Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #48 on: September 03, 2019, 01:16:00 AM »
Well done on deciphering it. I guess that mystery is finally solved! That equality is very strange indeed, I guess these values are 32 bit, so for this equality to happen by coincidence would be fantastically unlikely.

I am a little unclear on which part of the corruption takes place in the first vs the second time the game is saved.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #49 on: September 03, 2019, 01:59:08 PM »
Pente, the game set the value to 0 first, then at a later check it translated the 0 to mean a null pointer, so it set the valid ID to -1. I believe it is a union field that can be either an ID or a pointer based on context and where it is used.

While random, I was only seeing about a dozen values come up like 68, 10, etc. I suspect by random there are still only s few choices available. I wonder if the specific hardware implementation could affect the likelihood of different values coming up.

It may still be awhile before the fix is implemented.

Brett