https://bugs.winehq.org/show_bug.cgi?id=47633
Bug ID: 47633 Summary: Guild Wars quits silently after the splash screen Product: Wine Version: 4.14 Hardware: x86 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: julliard@winehq.org Regression SHA1: 0116660dd80b38da8201e2156adade67fc2ae823 Distribution: ArchLinux
Created attachment 65065 --> https://bugs.winehq.org/attachment.cgi?id=65065 plain terminal output
After starting Guild Wars I can see the "Connecting to ArenaNet..." screen for a moment then the game quits abruptly. This was caused by commit 0116660dd80b38da8201e2156adade67fc2ae823 (the game starts properly with the previous commit). Please let me know if you need debug logs.
https://bugs.winehq.org/show_bug.cgi?id=47633
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #1 from Paul Gofman gofmanp@gmail.com --- Created attachment 65080 --> https://bugs.winehq.org/attachment.cgi?id=65080 tweak
Does the attached patch fix it? Can you please attach a compressed output of "objdump -t <kernelbase.dll>", where <kernelbase.dll> is Wine's 'kernelbase.dll' (32 bit) from the Wine binaries used to run the game?
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- sorry, "objdump -d ...", not objdump -t
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #3 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 65083 --> https://bugs.winehq.org/attachment.cgi?id=65083 objdump -d kernelbase.dll
(In reply to Paul Gofman from comment #1)
Created attachment 65080 [details] tweak
Does the attached patch fix it? Can you please attach a compressed output of "objdump -t <kernelbase.dll>", where <kernelbase.dll> is Wine's 'kernelbase.dll' (32 bit) from the Wine binaries used to run the game?
The patch fixes the problem.
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Looks like a compiler problem. Below is the code of SetThreadStackGuarantee() function. It gets stack pointer misplaced upon return from its main execution path (see code snippet below). I've got the same problem with the other application, application crashes after the call to SetThreadStackGuarantee() stub (from native .Net). I get it with i686-w64-mingw32-gcc 8.3.0.
The problem is not there if DECLSPEC_HOTPATCH is removed. In this case stack frame is not generated.
-------------------------- 71279480 _SetThreadStackGuarantee@4: 71279480: 8b ff mov %edi,%edi
71279482: 55 push %ebp 71279483: 8b ec mov %esp,%ebp
71279485: a1 88 72 29 71 mov 0x71297288,%eax 7127948a: 8d 50 01 lea 0x1(%eax),%edx 7127948d: 89 15 88 72 29 71 mov %edx,0x71297288 71279493: 85 c0 test %eax,%eax 71279495: 75 09 jne 712794a0 <_SetThreadStackGuarantee@4+0x20> 71279497: f6 05 34 f1 27 71 01 testb $0x1,0x7127f134 7127949e: 75 10 jne 712794b0 <_SetThreadStackGuarantee@4+0x30> 712794a0: b8 01 00 00 00 mov $0x1,%eax
; 'leave' or similar is missing here, stack pointer is 4 bytes misplaced upon return. 712794a5: c2 04 00 ret $0x4
712794a8: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi 712794af: 90 nop 712794b0: 83 ec 28 sub $0x28,%esp 712794b3: 8b 45 08 mov 0x8(%ebp),%eax 712794b6: c7 44 24 0c 02 72 28 movl $0x71287202,0xc(%esp) 712794bd: 71 712794be: 89 44 24 10 mov %eax,0x10(%esp) 712794c2: c7 44 24 08 3c 72 28 movl $0x7128723c,0x8(%esp) 712794c9: 71 712794ca: c7 44 24 04 34 f1 27 movl $0x7127f134,0x4(%esp) 712794d1: 71 712794d2: c7 04 24 00 00 00 00 movl $0x0,(%esp) 712794d9: e8 62 f1 ff ff call 71278640 <_wine_dbg_log.constprop.0> 712794de: b8 01 00 00 00 mov $0x1,%eax
; stack pointer is correct on this path 712794e3: c9 leave 712794e4: c2 04 00 ret $0x4 --------------------
I also tested and could reproduce the compilation problem with the following small test program with gcc 9.1.1 (compile with 'gcc -m32 -O2 -g') and i686-w64-mingw32-gcc 8.3.0 (compile with '-O2 -g').
------------------ #include <stdio.h>
unsigned int __attribute__ ((noinline)) __attribute__((__stdcall__)) __attribute__((__ms_hook_prologue__)) test_func( unsigned long *size ) { static int once;
if (once++ == 0) printf("(%p): stub\n", size); return 1; }
int main(int argc, char **argv) { printf("%#x.\n", test_func(NULL)); printf("%#x.\n", test_func(NULL)); } -------------------- ------------------
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- I have filed a bug report to gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489
https://bugs.winehq.org/show_bug.cgi?id=47633
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #6 from joaopa jeremielapuree@yahoo.fr --- This bug affects Captvty too.
https://bugs.winehq.org/show_bug.cgi?id=47633
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |505be3a0a2afeae3cebeaad48fc | |5f32e0b0336b7
--- Comment #7 from Béla Gyebrószki gyebro69@gmail.com --- At least for Guild Wars, the problem is fixed with https://source.winehq.org/git/wine.git/commit/505be3a0a2afeae3cebeaad48fc5f3...
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #8 from Paul Gofman gofmanp@gmail.com --- Yes, SetThreadStackGuarantee() does not hit the bug anymore, but the similar problems like in SetProcessWorkingSetSize() from bug #47649 is still there. It seems the bug is triggered for __ms_hook_prologue__ under the following conditions:
- compiler decides that stack frame in prologue / epilogue is required for at least some of the control paths; - there is also quick return path in function which bypasses function's "official" prologue / epilogue; this path is then broken.
This happens in stubs if there is just FIXME in a stub or similar. Such a stub will crash if Wine is run, e. g, with WINEDEBUG=-all flag, but otherwise will not as the path with actual print code uses stack frame and is not broken. The SetProcessWorkingSetSize() is crashing because it has WARN instead of FIXME, that crash can be worked around by WINEDEBUG=warn+process. The issue is less likely to be present in implemented functions.
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.15.
https://bugs.winehq.org/show_bug.cgi?id=47633
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.15.
https://bugs.winehq.org/show_bug.cgi?id=47633
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.15.
-
wine-bugs＠winehq.org