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

Offline pente

  • Newbie
  • *
  • Posts: 30
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: 4763
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: 879
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: 30
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: 879
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: 30
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: 879
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: 4763
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: 30
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #33 on: Today at 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.