Author Topic: Building duplication glitch  (Read 4344 times)

Offline pente

  • Newbie
  • *
  • Posts: 38
Building duplication glitch
« on: March 31, 2019, 10:04:00 PM »
Ages ago when I first played Outpost 2, I happened to run into the building duplication glitch by chance (I got a free residence), but never succeeded in pulling it off again. Well, after watching Crow's Eden campaign speedrun I decided to see if I could pull it off using his technique.

As it turns out, doing it successfully is way easier than I expected. I loaded up the Plymouth Starship II colony mission (which is a land rush) and started plopping down Common Ore Smelters, and got up to 12 of them before the game crashed, without having lost the kit. Screenshot below:


Offline Crow!

  • Jr. Member
  • **
  • Posts: 74
Re: Building duplication glitch
« Reply #1 on: April 01, 2019, 01:20:55 AM »
I haven't encountered that particular crash.  Can't say I'm surprised by it, though.

Another way to crash the game with this is to clone guard posts.  The first deployed guard post takes the turret from the structure kit, and if you try to deploy the turretless guard post, the game crashes when the building completes.
Speedruns, my FFIV game randomizer, and more can be found at my twitch page:
https://twitch.tv/iicrowii

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: Building duplication glitch
« Reply #2 on: April 01, 2019, 10:45:13 AM »
Did you click "Show Details? :)

A crash address can provide quite a lot of insight into what exactly went wrong. Failing that, a stack trace or stack dump is also quite valuable.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Building duplication glitch
« Reply #3 on: April 01, 2019, 02:14:41 PM »
Wait really? I did not expect that information would be useful. I didn't click Show Details but I still have some information that got dumped into the terminal, maybe it is what you are looking for.

Incidentally I gave the glitch another try, but didn't do quite as well on my second attempt. I got 8 smelters and 11 structure factories down by the time I used up the kits. No crashes :)

Here's the stuff in the terminal:

Code: [Select]
wine: Unhandled page fault on write access to 0x00000000 at address 0x4582920 (thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x04582920).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:04582920 ESP:0033afc3 EBP:0033fcd0 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000000 EBX:00000018 ECX:1100cda3 EDX:000218a0
 ESI:045828f8 EDI:04582934
Stack dump:
0x0033afc3:  00045700 3282e400 00000200 00000700
0x0033afd3:  0090ba00 00140000 00a20000 00000500
0x0033afe3:  00045800 32820400 00000200 00000700
0x0033aff3:  0098f800 00140000 00a44000 00000500
0x0033b003:  00045900 32812400 00000200 00000500
0x0033b013:  01693600 00140000 0084c000 00000f00
Backtrace:
=>0 0x04582920 (0x0033fcd0)
0x04582920: addb        %al,0x0(%eax)
Modules:
Module  Address                 Debug info      Name (35 modules)
PE        360000-  3d0000       Deferred        out2res
PE        400000-  5bc000       Deferred        outpost2
PE      10000000-10011000       Deferred        op2ext
PE      11000000-11013000       Export          cps2
PE      7b420000-7b5d1000       Deferred        kernel32
PE      7bc10000-7bc14000       Deferred        ntdll
PE      7d150000-7d154000       Deferred        dsound
PE      7d1d0000-7d1d3000       Deferred        winealsa
PE      7d340000-7d348000       Deferred        oleaut32
PE      7d580000-7d584000       Deferred        mmdevapi
PE      7d7e0000-7d7e3000       Deferred        msvcr120
PE      7d8c0000-7d8c4000       Deferred        uxtheme
PE      7dc30000-7dc33000       Deferred        concrt140
PE      7dc60000-7dc64000       Deferred        winex11
PE      7df10000-7df13000       Deferred        api-ms-win-crt-heap-l1-1-0
PE      7df30000-7df33000       Deferred        api-ms-win-crt-stdio-l1-1-0
PE      7df40000-7df43000       Deferred        api-ms-win-crt-string-l1-1-0
PE      7df50000-7df53000       Deferred        api-ms-win-crt-runtime-l1-1-0
PE      7df70000-7df73000       Deferred        vcruntime140
PE      7dfa0000-7dfa4000       Deferred        ucrtbase
PE      7e0c0000-7e0c3000       Deferred        msvcp140
PE      7e1b0000-7e1b4000       Deferred        iphlpapi
PE      7e1e0000-7e1e4000       Deferred        ws2_32
PE      7e210000-7e214000       Deferred        wsock32
PE      7e230000-7e234000       Deferred        imm32
PE      7e260000-7e263000       Deferred        usp10
PE      7e2a0000-7e2f2000       Deferred        comctl32
PE      7e3e0000-7e3e9000       Deferred        msacm32
PE      7e410000-7e489000       Deferred        winmm
PE      7e4d0000-7e4d4000       Deferred        rpcrt4
PE      7e560000-7e588000       Deferred        ole32
PE      7e6c0000-7e6c4000       Deferred        advapi32
PE      7e730000-7e737000       Deferred        gdi32
PE      7e870000-7e970000       Deferred        user32
PE      7eff0000-7eff4000       Deferred        version
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Z:\home\user\games\outpost2\137\Outpost2.exe
        0000007a   15
        00000077   15
        0000006b    0
        0000006a    0
        00000009    0 <==
0000000e services.exe
        00000020    0
        0000001b    0
        00000013    0
        00000010    0
        0000000f    0
00000011 winedevice.exe
        00000018    0
        00000017    0
        00000016    0
        00000012    0
00000019 plugplay.exe
        0000001d    0
        0000001c    0
        0000001a    0
0000001e winedevice.exe
        00000022    0
        00000021    0
        0000001f    0
00000025 explorer.exe
        00000031    0
        0000002c    0
        0000002b    0
        00000026    0
System information:
    Wine build: wine-4.4
    Platform: i386 (WOW64)
    Version: Windows 7
    Host system: Linux
    Host version: 4.20.4-gentoo

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Building duplication glitch
« Reply #4 on: April 01, 2019, 02:17:07 PM »
I sort of assumed if you got a crash after duplicating 12 smelters then it is only fair at that point :D

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: Building duplication glitch
« Reply #5 on: April 02, 2019, 09:27:05 AM »
Hmm, the crash address doesn't appear to be from Outpost2.exe. In fact, it's not in any of the list PE modules. I suspect the crash might be coming from Wine itself.

The crash address is EIP:04582920, which is identified in the first line of the dump as ... at address 0x4582920.

The instruction at that address is (AT&T/GAS syntax):
Code: [Select]
0x04582920: addb        %al,0x0(%eax)

In AT&T/GAS (Gnu As(sembler)) syntax, the source and destination operands are reversed from Intel syntax. GAS syntax uses OpCode Source, Destination. That means the instruction is trying to add the byte in the al register to the memory location in the eax register, offset by a constant of 0 bytes.

The eax register contains the value 0 (EAX:00000000 under Register dump). That would denote the nullptr value. Typically the OS reserves that section of the address space, and doesn't allow access to it, mostly as a way of detecting attempts to dereference a nullptr. As such, that address will not be valid when accessing the page tables, which results in the unhandled page fault that crashed the program.

There is insufficient stack dump or backtrace to determine a point of origin within Outpost2.exe. Hence I'm afraid I can't determine a root Outpost 2 cause from the posted information.

Offline pente

  • Newbie
  • *
  • Posts: 38
Re: Building duplication glitch
« Reply #6 on: April 02, 2019, 05:27:55 PM »
Ah, well, thanks for looking into it. I wasn't expecting to find any sort of resolution to the crash, I mostly just wanted to encourage other people to try out the glitch for themselves.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: Building duplication glitch
« Reply #7 on: April 03, 2019, 05:00:57 PM »
If you have a way of obtaining more information, it may still be possible to track down a root cause. Maybe you could get a crash dump file, or find a way of viewing more of the stack or the backtrace. Finding the last active method from Outpost2.exe is usually what reveals the problem.

Failing that, finding a way to easily reproduce the problem in a reliable way, such as a saved game from just before, may also help.