[Bug 52475] Shogun Total War 2 crashes on start up. (Main Application.)
WineHQ Bugzilla
wine-bugs at winehq.org
Wed Feb 16 05:13:40 CST 2022
https://bugs.winehq.org/show_bug.cgi?id=52475
--- Comment #4 from Patrick Hibbs <hibbsncc1701 at gmail.com> ---
Created attachment 71867
--> https://bugs.winehq.org/attachment.cgi?id=71867
Game memory map during init. Dumped from /proc using gdb.
Some additional info that I've worked out:
As winedbg cannot get a trace, I've dumped the memory map via gdb during the
game's init to get a list of it's mapped addresses. (That's been attached to
this report.)
As a sidenote, this game has most of it's logic inside of a DLL called
Shogun2.dll instead of it's main exe. The main exe simply acts as the initial
entry point for the game, does some relocations, and makes some VirtualAlloc()
calls to allocate some (rather large) buffers before handing those buffers off
as an array to the dll's entry_point() function (via LoadLibraryA() /
GetProcAddress()).
The crashing instruction at 578C4345 / 579F4345 is within Shogun2.dll @ (Base +
0x874345) The function for that address starts at (Base + 0x874220) and looks
like this:
---- snip ----
10874220 83 ec 1c SUB ESP,0x1c
10874223 53 PUSH EBX
10874224 55 PUSH EBP
10874225 56 PUSH ESI
10874226 57 PUSH EDI
10874227 8b 44 24 30 MOV EAX,dword ptr [ESP + param_1]
1087422b d9 41 30 FLD dword ptr [this + 0x30]
1087422e 8b 10 MOV EDX,dword ptr [EAX]
10874230 8b 40 04 MOV EAX,dword ptr [EAX + 0x4]
10874233 f3 0f 10 MOVSS XMM1,dword ptr [this + 0x20]
49 20
10874238 89 44 24 18 MOV dword ptr [ESP + local_14],EAX
1087423c f3 0f 58 ADDSS XMM1,dword ptr [ESP + local_14]
4c 24 18
10874242 89 54 24 14 MOV dword ptr [ESP + local_18],EDX
10874246 f3 0f 10 MOVSS XMM0,dword ptr [ESP + local_18]
44 24 14
1087424c f3 0f 58 ADDSS XMM0,dword ptr [this + 0x1c]
41 1c
10874251 f3 0f 11 MOVSS dword ptr [ESP + local_14],XMM1
4c 24 18
10874257 8b 44 24 18 MOV EAX,dword ptr [ESP + local_14]
1087425b f3 0f 10 MOVSS XMM1,dword ptr [this + 0x2c]
49 2c
10874260 89 44 24 20 MOV dword ptr [ESP + local_c],EAX
10874264 d8 4c 24 20 FMUL dword ptr [ESP + local_c]
10874268 f3 0f 11 MOVSS dword ptr [ESP + local_18],XMM0
44 24 14
1087426e 8b 54 24 14 MOV EDX,dword ptr [ESP + local_18]
10874272 d9 5c 24 20 FSTP dword ptr [ESP + local_c]
10874276 8b 44 24 20 MOV EAX,dword ptr [ESP + local_c]
1087427a 89 54 24 1c MOV dword ptr [ESP + local_10],EDX
1087427e f3 0f 59 c8 MULSS XMM1,XMM0
10874282 f3 0f 10 MOVSS XMM0,dword ptr [DAT_11632090]
= BF000000h
05 90 20
63 11
1087428a f3 0f 11 MOVSS dword ptr [ESP + local_10],XMM1
4c 24 1c
10874290 8b 54 24 1c MOV EDX,dword ptr [ESP + local_10]
10874294 89 54 24 24 MOV dword ptr [ESP + local_8],EDX
10874298 89 44 24 28 MOV dword ptr [ESP + local_4],EAX
1087429c f3 0f 11 MOVSS dword ptr [ESP + local_1c],XMM0
44 24 10
108742a2 d9 44 24 28 FLD dword ptr [ESP + local_4]
108742a6 dc c0 FADD ST0,ST0
108742a8 d8 44 24 10 FADD dword ptr [ESP + local_1c]
108742ac db 5c 24 30 FISTP dword ptr [ESP + param_1]
108742b0 d1 7c 24 30 SAR dword ptr [ESP + param_1],1
108742b4 8b 7c 24 30 MOV EDI,dword ptr [ESP + param_1]
108742b8 f3 0f 11 MOVSS dword ptr [ESP + local_18],XMM0
44 24 14
108742be d9 44 24 24 FLD dword ptr [ESP + local_8]
108742c2 dc c0 FADD ST0,ST0
108742c4 d8 44 24 14 FADD dword ptr [ESP + local_18]
108742c8 db 5c 24 10 FISTP dword ptr [ESP + local_1c]
108742cc d1 7c 24 10 SAR dword ptr [ESP + local_1c],1
108742d0 8b 74 24 10 MOV ESI,dword ptr [ESP + local_1c]
108742d4 8b d6 MOV EDX,ESI
108742d6 85 d2 TEST EDX,EDX
108742d8 89 54 24 14 MOV dword ptr [ESP + local_18],EDX
108742dc db 44 24 14 FILD dword ptr [ESP + local_18]
108742e0 7d 06 JGE LAB_108742e8
108742e2 d8 05 54 FADD dword ptr [DAT_11631554]
15 63 11
LAB_108742e8 XREF[1]:
108742e0(j)
108742e8 d8 6c 24 1c FSUBR dword ptr [ESP + local_10]
108742ec 8b c7 MOV EAX,EDI
108742ee 85 c0 TEST EAX,EAX
108742f0 89 44 24 14 MOV dword ptr [ESP + local_18],EAX
108742f4 db 44 24 14 FILD dword ptr [ESP + local_18]
108742f8 7d 06 JGE LAB_10874300
108742fa d8 05 54 FADD dword ptr [DAT_11631554]
15 63 11
LAB_10874300 XREF[1]:
108742f8(j)
10874300 8b 59 0c MOV EBX,dword ptr [this + 0xc]
10874303 d8 6c 24 20 FSUBR dword ptr [ESP + local_c]
10874307 8d 46 01 LEA EAX,[ESI + 0x1]
1087430a 3b d8 CMP EBX,EAX
1087430c 72 02 JC LAB_10874310
1087430e 8b d8 MOV EBX,EAX
LAB_10874310 XREF[1]:
1087430c(j)
10874310 8b 69 10 MOV EBP,dword ptr [this + 0x10]
10874313 8d 47 01 LEA EAX,[EDI + 0x1]
10874316 3b e8 CMP EBP,EAX
10874318 72 02 JC LAB_1087431c
1087431a 8b e8 MOV EBP,EAX
LAB_1087431c XREF[1]:
10874318(j)
1087431c 8b 51 04 MOV EDX,dword ptr [this + 0x4]
1087431f d9 e8 FLD1
10874321 8b 49 34 MOV this,dword ptr [this + 0x34]
10874324 d9 c0 FLD ST0
10874326 d8 e2 FSUB ST0,ST2
10874328 8b c2 MOV EAX,EDX
1087432a 0f af d5 IMUL EDX,EBP
1087432d d9 c9 FXCH
1087432f d8 e3 FSUB ST0,ST3
10874331 0f af c7 IMUL EAX,EDI
10874334 8d 3c 32 LEA EDI,[EDX + ESI*0x1]
10874337 d9 04 b9 FLD dword ptr [this + EDI*0x4]
1087433a 8d 3c 18 LEA EDI,[EAX + EBX*0x1]
1087433d d8 c9 FMUL ST1
1087433f 03 c6 ADD EAX,ESI
10874341 03 d3 ADD EDX,EBX
10874343 d8 cb FMUL ST3
10874345 d9 04 b9 FLD dword ptr [this + EDI*0x4] <--- CRASH
10874348 5f POP EDI
10874349 d8 cb FMUL ST3
1087434b 5e POP ESI
1087434c 5d POP EBP
1087434d 5b POP EBX
1087434e d8 cd FMUL ST5
10874350 de c1 FADDP
10874352 d9 04 81 FLD dword ptr [this + EAX*0x4]
10874355 de ca FMULP ST2
10874357 d9 c9 FXCH
10874359 de ca FMULP ST2
1087435b de c1 FADDP
1087435d d9 04 91 FLD dword ptr [this + EDX*0x4]
10874360 de ca FMULP ST2
10874362 d9 c9 FXCH
10874364 de ca FMULP ST2
10874366 de c1 FADDP
10874368 83 c4 1c ADD ESP,0x1c
1087436b c2 04 00 RET 0x4
---- snip ----
The function is clearly part of a C++ object and is called multiple times
through out Shogun2.dll. All of the calls trace back out to another function
(Base + f2f700) where we start seeing pointers to strings like "Tree Display"
and "Wind Gauge Display". Which, along with the floating point opcodes makes me
think that this is some GUI init code. Unfortunately, I've yet to be able to
backtrace it any further.
The following is conjecture: As the failing instruction seems to be accessing
part of the stack, my guess is that the function never quite worked properly at
all under wine. The only reason it did so previously was because the pointer
math wound up giving it a valid page address, and as of the blamed commit, the
stack for this function no longer lines up that way. The game clearly doesn't
expect this opcode or indeed this function to fail with an exception. As none
of the calls to it that I have seen thus far include any exception handler
specifically for it. Without seeing an allocation for this object however, I
have no idea what it was expecting.
If anyone has some suggestions for debugging this I would love to hear them. As
for myself, while I was trying to debug this I ran into a crash on read access
in ntdll:HEAP_FindFreeBlock. (Triggered by a call I made to HeapAlloc to
allocate a 4096 byte buffer.) It seems the first LIST_ENTRY() call returned a
NULL pointer. So I've been trying to hunt that one down.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list