https://bugs.winehq.org/show_bug.cgi?id=49782
Bug ID: 49782 Summary: Elite Dangerous Horizons: crashes with wine64 5.16 Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: klaus.heissler@tutanota.com Distribution: ---
Created attachment 68098 --> https://bugs.winehq.org/attachment.cgi?id=68098 terminal output
The launcher and game starts normally and gets all the way to the main menu where it tries to connect to game servers for ~10 seconds and crashes after that. Works normally when downgraded to wine64 5.15.
Regression Testing: (This was done in the existing prefix as I had problems installing dotnet40 to a new one)
75e616d52b452d37cc93f492d47eba641f9741c1 is the first bad commit commit 75e616d52b452d37cc93f492d47eba641f9741c1 Author: Alexandre Julliard julliard@winehq.org Date: Thu Aug 27 11:41:36 2020 +0200
ntdll: Clear the syscall frame on return instead of popping the previous one.
Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/ntdll/unix/signal_arm.c | 23 +++++++------- dlls/ntdll/unix/signal_arm64.c | 38 ++++++++++------------- dlls/ntdll/unix/signal_i386.c | 48 +++++++++++++---------------- dlls/ntdll/unix/signal_x86_64.c | 63 +++++++++++++++++--------------------- tools/winebuild/import.c | 67 ++++++++++++++++++----------------------- 5 files changed, 105 insertions(+), 134 deletions(-)
Operating System: Arch Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 Kernel Version: 5.8.5-arch1-1 OS Type: 64-bit Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31,4 GiB of RAM Graphics Processor: GeForce GTX 1070/PCIe/SSE2 // Nvidia proprietary 450.66-16
https://bugs.winehq.org/show_bug.cgi?id=49782
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |dark.shadow4@web.de Regression SHA1| |75e616d52b452d37cc93f492d47 | |eba641f9741c1
https://bugs.winehq.org/show_bug.cgi?id=49782
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash@kolahilft.de
--- Comment #1 from kolAflash kolAflash@kolahilft.de --- Nearly the same here.
wine-staging-5.11 Ingame main menu is connecting to servers normally.
wine-staging-5.15.2 Ingame main menu is connecting to servers normally.
wine-staging-5.16 Ingame main menu is not connecting to servers.
wine-staging-5.17.2 Crashing when connecting to servers in ingame main menu.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #2 from kolAflash kolAflash@kolahilft.de --- I've done some git bisect on Wine (without staging) and this seems to be the first bad commit. https://source.winehq.org/git/wine.git/commit/75e616d52b452d37cc93f492d47eba...
ntdll: Clear the syscall frame on return instead of popping the previous one.
With the previous commit everything is still working fine. https://source.winehq.org/git/wine.git/commit/4e4b1d1406f30764c1a1f4861a182f...
Btw.: wine-staging-5.18 is still broken.
https://bugs.winehq.org/show_bug.cgi?id=49782
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brendan@redmandi.com
--- Comment #3 from Brendan McGrath brendan@redmandi.com --- I can confirm kolAflash's findings. I just did a git bisect myself and got the same result.
Using the latest master commit (commit 2ee75bf9ade3e90f10ffe4236c8c95d817402392) and reverting the changes made in commit 75e616d52b452d37cc93f492d47eba641f9741c1 to: - dlls/ntdll/unix/signal_x86_64.c; and - tools/winebuild/import.c
allows the game to work again.
https://bugs.winehq.org/show_bug.cgi?id=49782
Peter van de Werken peter@van-de-werken.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@van-de-werken.nl
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #4 from kolAflash kolAflash@kolahilft.de --- Just tested wine-staging-5.19. Bug is still present.
patch -R with 75e616d52b452d37cc93f492d47eba641f9741c1 makes EliteDangerous work with wine-staging-5.19.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #5 from Brendan McGrath brendan@redmandi.com --- Created attachment 68386 --> https://bugs.winehq.org/attachment.cgi?id=68386 A work-around for this issue
I've attached a patch which fixes this issue. It's basically a partial revert of commit 75e616d52b452d37cc93f492d47eba641f9741c1.
I haven't worked out why this fixes the issue; so it's probably more accurate to call this patch a work-around.
https://bugs.winehq.org/show_bug.cgi?id=49782
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #6 from Paul Gofman pgofman@codeweavers.com --- I've tested the game. The failing sequence is:
1. Application calls WaitForMultipleObjects(). 2. select wineserver call in ntdll/unix/server.c:server_select() first gets STATUS_KERNEL_APC for APC_ASYNC_IO/. 3. The async IO callback is WS2_async_recv, which currently calls into ntdll through syscall thunks. This effectively resets syscall frame to NULL. 4. next select wineserver call returns STATUS_USER_APC. invoke_apc() called from server_wait() crashes because of NULL syscall frame.
The problem is in step 3, the async callbacks are not supposed to make calls through syscall thunks. AFAIK the move of those callbacks into ntdll.so is being worked on, this bug should be fixed once that is complete.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #7 from Brendan McGrath brendan@redmandi.com --- Thanks Paul. I appreciate you taking the time to take a look and report your findings. Now I know why this work-around works.
Is the reason for this change to potentially provide anti-cheat support?
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #8 from Paul Gofman pgofman@codeweavers.com --- (In reply to Brendan McGrath from comment #7)
Is the reason for this change to potentially provide anti-cheat support?
If by anti-cheat support you mean a support for specific features for kernel mode device drivers typically used by kernel mode anti cheats, then no, it is not related. In some other aspects it might, to some extent.
The discussion of the ideas behind these changes probably falls far away from the purpose of the bugtracker. I suppose the better places are #winehackers IRC channel or wine-devel@winehq.org mailing list.
Very briefly, Wine is going to have all the DLLs used by Win applications directly built as PE (using mingw). The access to the host specific (native) APIs is supposed to cross a well defined boundary, which boundary conceptually (has no relation to kernel mode and other drivers) corresponds in some way to user space / kernel space boundary on Windows. In this regard, "kernel space" has absolutely nothing to do with kernel mode drivers (how Wine loads a device driver is a separate story not related here) or how that looks like in the real kernel on Windows, but interfacing from the user space libraries is supposed to look as close as possible to how that is done on Windows (probably more close when it is ntdll and not that close when it comes to some other libs requiring host API interaction).
This helps a bunch of real cases covered by numerous bugs, including (but not limited to): - comparing in-memory image to the on disk image for system library (done by some DRMs); - hotpatching ("detouring") system functions (DRM related or not, e. g., for implementing some sort of virtual file system). The dependencies between the hotpatched functions should match Windows in order for that to work; - a lot of fine details in system functions behaviour (on which apps, mostly DRMs, sometimes depend) which is very hard to get right without separating the native host part.
These are just the examples, there is more involved.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #9 from Brendan McGrath brendan@redmandi.com --- OK - thanks again Paul. I have no idea how anti-cheat works, but I was thinking it was something that might care about the low level operation of an application. I didn't think of DRM.
(In reply to Paul Gofman from comment #8)
The discussion of the ideas behind these changes probably falls far away from the purpose of the bugtracker.
Agreed - but thanks for answering anyway.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #10 from kolAflash kolAflash@kolahilft.de --- Problem persists in wine-staging-5.20.
Commit 75e616d52 can't be reverted and attachment 68386 can't be applied any more without conflicts on wine-5.20 (even without staging).
By the way: Someone might change the bug status to confirmed / new?
https://bugs.winehq.org/show_bug.cgi?id=49782
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #11 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Marking confirmed.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49782
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #68386|0 |1 is obsolete| |
--- Comment #12 from Brendan McGrath brendan@redmandi.com --- Created attachment 68541 --> https://bugs.winehq.org/attachment.cgi?id=68541 An updated work-around for this issue which applies to lastest master commit
Issue is still present as of commit 03eaa2cc93e5e2ea4c36495870c268797aea3ca8.
Attached is an updated patch that applies to this commit.
Note that I was able to apply the previous patch with 'git apply -3 fix_49782.patch'; but it did result in a conflict (which I subsequently fixed).
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #13 from kolAflash kolAflash@kolahilft.de --- attachment 68541 by Brendan McGrath works fine for wine-staging-5.20.
For wine-staging-5.21 I was also able to apply attachment 68541 and compile. But I couldn't start the launcher or the game because of this new bug in wine-5.21:
Elite Dangerous Launcher (wine-5.21): AccessViolationException Protected Memory https://bugs.winehq.org/show_bug.cgi?id=50110
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #14 from Brendan McGrath brendan@redmandi.com --- This bug appears to be fixed in 5.22
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #15 from Brendan McGrath brendan@redmandi.com --- Actually not. Sorry for the noise. After a full clean and rebuild, the problem persists.
https://bugs.winehq.org/show_bug.cgi?id=49782
sonnyroaming@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sonnyroaming@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=49782
alexandref75@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexandref75@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #16 from kolAflash kolAflash@kolahilft.de --- Still a problem with wine-staging-6.0-rc1. (attachment 68541 by Brendan McGrath still helps)
(In reply to Paul Gofman from comment #6)
[...] AFAIK the move of those callbacks into ntdll.so is being worked on, this bug should be fixed once that is complete.
I'd be happy if this callback regression would be fixed before releasing wine-6.0 stable.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #17 from kolAflash kolAflash@kolahilft.de --- Still a problem with wine-6.0-rc3.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #18 from Paul Gofman pgofman@codeweavers.com --- Should be fixed by 8b8ddffa2152832908ced42191fa19dcb64d900e
https://bugs.winehq.org/show_bug.cgi?id=49782
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |8b8ddffa2152832908ced42191f | |a19dcb64d900e Status|NEW |RESOLVED
--- Comment #19 from Alexandre Julliard julliard@winehq.org --- Marking fixed.
https://bugs.winehq.org/show_bug.cgi?id=49782
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.0-rc4.
https://bugs.winehq.org/show_bug.cgi?id=49782
--- Comment #21 from kolAflash kolAflash@kolahilft.de --- 6.0-rc4 is working fine. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=49782
Peter van de Werken peter@van-de-werken.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|peter@van-de-werken.nl |