https://bugs.winehq.org/show_bug.cgi?id=52475
--- Comment #4 from Patrick Hibbs hibbsncc1701@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.