https://bugs.winehq.org/show_bug.cgi?id=49412
Bug ID: 49412 Summary: Wine 5.10 breaks League Of Legends Product: Wine-staging Version: 5.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: matias.nicolas.zc@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Regression SHA1: 7b78338b078a7a55c5851a91064ef70836f4c996 Distribution: ---
Created attachment 67491 --> https://bugs.winehq.org/attachment.cgi?id=67491 Pass syscall_dispatcher to NtCreateThreadEx
First of all, this is not the same as Bug 49373, that one doesn't affect the alternative patch from Bug 47198.
Stating with wine 35b063a4 + staging 7b78338b, the game doesn't start. The following message appears in the terminal every couple of seconds (with different thread ids):
``` 0184:err:ntdll:RtlpWaitForCriticalSection section 0x7bd07a40 "loader.c: loader_section" wait timed out in thread 0184, blocked by 0024, retrying (60 sec) ``` __________________________________________________
This can be reproduced by running the following executable, no need to have an account: `wine League of Legends/Game/League of Legends.exe`
Tested with wine 67ef5151 + staging 02913f75 (the last staging commit at the moment of testing) The game also needs the alternative patch from Bug 47198 + `echo 0 > /proc/sys/abi/vsyscall32`
I have an updated patch for Bug 47198 that applies over wine-git+staging in my copr repo: https://copr-dist-git.fedorainfracloud.org/cgit/manizuca/wine-lol/wine.git/t...
__________________________________________________
As i said, this bug is present since wine 35b063a4 with the staging rebasing from 7b78338b
Specifically, the `WOW32Reserved` assignation from the `0003-winebuild-Generate-syscall-thunks-for-ntdll-exports` patch was moved to loader.c, since the thread creation function was moved to the Unix library, but apparently that assignation needs to be in thread creation function.
The attached patch moves back that assignation, by passing a syscall_dispatcher reference to the Unix library. Sadly, starting with wine 33c750f5, NtCreateThreadEx is called from unix/server.c. Since i couldn't find how to get syscall_dispatcher from there, I'm reverting that commit to make League Of Legends work.
In summary, I can make LoL work with wine-git + staging + reverting 33c750f5 + the attached patch + the alternative patch from Bug 49373
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #1 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67492 --> https://bugs.winehq.org/attachment.cgi?id=67492 alternative_patch_by_using_a_fake_cs_segment
Since the patch in my repo is constantly updated, this is the alternative patch from Bug 47198 that applies over wine 67ef5151 + staging 02913f75
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #2 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67493 --> https://bugs.winehq.org/attachment.cgi?id=67493 revert ntdll: Use NtCreateThreadEx() for remote thread creation.
Also, the rebased patch to revert 33c750f5
https://bugs.winehq.org/show_bug.cgi?id=49412
juliansperling@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juliansperling@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #3 from juliansperling@gmail.com --- I would like to add that this is the behavior I observe post https://bugs.winehq.org/show_bug.cgi?id=49025 with the patched gcc version, so I am unsure this is really a separate issue
https://bugs.winehq.org/show_bug.cgi?id=49412
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #4 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Compiling wine-staging 5.12 with attachment 67491 fails with '__wine_syscall_dispatcher' undeclared, because the patchset winebuild-Fake_Dlls is disabled.
--- quote from winebuild-Fake_Dlls/definition --- # As of 43be3507c04, unless I've misread, ntdll.dll no longer has the chance to # run code before ntdll.so performs process initialization. Unfortunately, # ntdll.so is still making calls to Nt* exports during that process # initialization, which in practice means it's calling syscall thunks. In order # for this series to work, we need to poke __wine_syscall_dispatcher into the # TEB before those calls are made. Fixing this would require a nontrivial amount # of effort, which will be obviated as soon as Alexandre finishes splitting # ntdll upstream. Disabled: true --- end quote ---
This bug is blocked until that is resolved.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49412
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67492|0 |1 is obsolete| |
--- Comment #5 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67716 --> https://bugs.winehq.org/attachment.cgi?id=67716 alternative_patch_by_using_a_fake_cs_segment
The patchset is enabled again (as of wine 54b2a10 and wine-staging 884f646), but seems to be different so the NtCreateThreadEx patches don't apply.
Now when trying to run Lol with an updated alternative-patch (attached), wine end execution with a `0024:err:seh:setup_exception_record stack overflow 104 bytes in thread 0024 eip 00000000 esp 002212c4 stack 0x220000-0x221000-0x320000` message.
I don't know it this is a new bug, or a re-manifestation of a previous one because of the re-write (maybe Bug 45573, which is said to be fixed by the re-written winebuild-pe_syscall_thunks patchset. That one was debugged by Andrew Wesie, but I don't know how he did it)
Should I create a new Bug for this?
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #6 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67717 --> https://bugs.winehq.org/attachment.cgi?id=67717 full console output
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #7 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67718 --> https://bugs.winehq.org/attachment.cgi?id=67718 seh trace log, around the setup_exception_record error
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #8 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Matías Zúñiga from comment #5)
Should I create a new Bug for this?
Hello,
No. I copied your feedback on that bug.
Let's wait for replies there.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49412
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #9 from Paul Gofman pgofman@codeweavers.com --- Created attachment 67727 --> https://bugs.winehq.org/attachment.cgi?id=67727 Also put syscall dispatcher address to WOW32Reserved
I don't have League of Legends to try, but IIRC this particular part of LoL specifics was about making 64 bit syscalls from 32 bit code by calling Teb->WOW32Reserved address. This address indeed was there in the previous version of syscall thunks but is not there now. Does the attached patch (on top of current Staging) change anything? This doesn't remove the need in any other LoL specific patches which were used previously on top of Staging before 5.9.
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #10 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67729 --> https://bugs.winehq.org/attachment.cgi?id=67729 calls and rets
Hi Paul, Sadly, your patch doesn't help. I think it'll be needed to make LoL work, but there is another bug playing here.
The only difference is that now the error is logged as "err:virtual:virtual_setup_exception", but that is the result of a recent change in wine.
Attached is the list of the last Call/Ret's I got from the trace-log (filtered for the thread that throws the error), in case that helps to understand where the problem might be (All the *Heap* calls where removed from the file, because there were too many)
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #11 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67730 --> https://bugs.winehq.org/attachment.cgi?id=67730 Trace log for the thread 0024
Also, here is the tail of the full trace of the thread 0024.
It starts with the KERNEL32.CheckRemoteDebuggerPresent call, as with the previous file, and doesn't include the 'trace:seh:call_stack_handlers' lines, because they flood the output. Could it be that the big number of call_stack_handlers produces the overflow? (I'm referring to the '0024:trace:seh:call_stack_handlers' lines that can be seen in the 'seh trace log' file)
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #12 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67731 --> https://bugs.winehq.org/attachment.cgi?id=67731 calls and rets of a working wine
For comparison, these are the calls after KERNEL32.CheckRemoteDebuggerPresent for a working wine (5.11+patches)
There are pretty much the same until two RtlReleaseSRWLockShared calls at the end (at this point, there are two 'dispatch_exception code=c0000005' on the trace of the comment above)
https://bugs.winehq.org/show_bug.cgi?id=49412
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67727|0 |1 is obsolete| |
--- Comment #13 from Paul Gofman pgofman@codeweavers.com --- Created attachment 67750 --> https://bugs.winehq.org/attachment.cgi?id=67750 Restore original Staging 32 bit syscall thunks format
Does this patch on top of current Staging change anything (this supersedes the previous patch from Comment #9 but again all the other custom patches which were required prior to 5.9 are still needed. Could you please also make sure that you are building PE dlls with mingw (e. g., that you have ntdll.dll and ntdll.so and not ntdll.dll.so in the built Wine)?
https://bugs.winehq.org/show_bug.cgi?id=49412
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67717|0 |1 is obsolete| | Attachment #67718|0 |1 is obsolete| | Attachment #67729|0 |1 is obsolete| | Attachment #67730|0 |1 is obsolete| | Attachment #67731|0 |1 is obsolete| |
--- Comment #14 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67757 --> https://bugs.winehq.org/attachment.cgi?id=67757 Trace output near the error.
Hi! Yes, I'm building with Mingw and have /usr/lib/wine/ntdll.dll & /usr/lib/wine/ntdll.so
With you new patch,the executions lasts for a little bit longer, but ends with a window saying "A critical error has occurred and the process must be terminated. Would you like to create a crash dump to aid the developers in troubleshooting this issue? This may take up to 5 minutes." (if I try to create the dump file, dbghelp:MiniDumpWriteDump shows "failed to initialize process", but that's probably because of the patch that fakes the CS segment)
I can't find anything obvious in the console output, attached is the tracelog that shows when the message of the error is being created, together with the temp files that LoL creates when something bad happens.
https://bugs.winehq.org/show_bug.cgi?id=49412
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67757|0 |1 is obsolete| |
--- Comment #15 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 67862 --> https://bugs.winehq.org/attachment.cgi?id=67862 Trace output near the error
While retesting this with wine-staging 5.14, I was able to get the dump file without problems. It's quite big, and I can upload it somewhere if asked, but for the moment I'm putting here the winedbg output:
``` $ winedbg /home/User/.wine/dosdevices/c:/users/User/Temp/PKMa869.tmp 00c4:fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for -04, bias 240, std (d/m/y): 5/04/2020, dlt (d/m/y): 6/09/2020 WineDbg starting on minidump on pid 0020 League of Legends.exe was running on #8 Intel Pentium Pro/II or AMD Athlon (71.1) CPUs on Windows Win7 (7601) [on wine-5.14 (Staging), on top of Linux (5.6.19-libre.300.fc32.gnu.x86_64)] Register dump: CS:0107 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:102966f0 ESP:0031d9a8 EBP:0031d9ec EFLAGS:00000206( - -- I - -P- ) EAX:00000001 EBX:00001000 ECX:15104e06 EDX:00000001 ESI:0031d9d0 EDI:0031e410 Stack dump: 0x0031d9a8: *** Invalid address 0x0031d9a8 ***
000c: sel=0067 base=00000000 limit=00000000 32-bit r-- Backtrace: =>0 0x0107:0x102966f0 EntryPoint+0xffffffff() in stub (0x0031d9ec) 00cc:fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for -04, bias 240, std (d/m/y): 5/04/2020, dlt (d/m/y): 6/09/2020 WineDbg starting on minidump on pid 0020 League of Legends.exe was running on #8 Intel Pentium Pro/II or AMD Athlon (71.1) CPUs on Windows Win7 (7601) [on wine-5.14 (Staging), on top of Linux (5.6.19-libre.300.fc32.gnu.x86_64)] Register dump: rip:0000000000000000 rsp:0031e4100000002b rbp:000010000031d9d0 eflags:00000000 ( - -- - - - ) rax:00003fff80000000 rbx:0000002b00000063 rcx:4003800000000000 rdx:0000006b00000020 rsi:15104e0600000001 rdi:0031d9ec00000001 r8:00000107102966f0 r9:0031d9a800000206 r10:0020027f0000002b r11:0032013300000000 r12:0031bc5800000000 r13:00001fa000000000 r14:000000000000ffff r15:0000000000000000 Stack dump: 0x0031e4100000002b: *** Invalid address 0x0031e4100000002b ***
Backtrace: =>0 0x0000000000000000 (0x000010000031d9d0) WineDbg starting on pid 0020 ```
This seems to confirm that the cause of the crash is the first of the two exceptions from the trace-log
I'm attaching an updated trace log, this time including the full output for pid 0020 (without removing the RtlAllocateHeap/HeapFree lines that usually flood the log)
https://bugs.winehq.org/show_bug.cgi?id=49412
Manuel mail+wine@m-reimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail+wine@m-reimer.de
--- Comment #16 from Manuel mail+wine@m-reimer.de --- Any news on this case? Seems like I'm running into this with the "glibc based patch". Client works well. Trying to launch a game hides the client for a few seconds and then it reappears and asks me to reconnect.
Seems like currently we are stuck with Wine 5.6 for playing LoL.
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #17 from Matías Zúñiga matias.nicolas.zc@gmail.com ---
Any news on this case? Seems like I'm running into this with the "glibc based patch". Client works well. Trying to launch a game hides the client for a few seconds and then it reappears and asks me to reconnect.
I haven't tried the glib based patch. To see if you are experiencing this bug, try to run `wine League of Legends/Game/League of Legends.exe`, you don't need to be logged in.
With the Paul Gofman applied, you should get a window saying "A critical error has occurred and the process must be terminated.", and the dump should be similar to the one in Comment 15.
Seems like currently we are stuck with Wine 5.6 for playing LoL.
You can use Wine 5.11 with the first two patches here (Comment 0 and Comment 2). I've been using 5.12-git for some time (commit 83a4549e9ba is the last one to work or, if you wanna easily apply wine staging, commit 13b2587d4f5 + staging b6c28187).
Wine 5.11 doesn't have esync tough, for that you need Wine 5.9 + revert commit fd7992972b252ed26
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #18 from Manuel mail+wine@m-reimer.de --- I don't get any error window. Also no crash dump in "Temp". The game just does not start. Client disappears for a few seconds and then reappears with the "Reconnect" button.
So maybe a different error but I can't debug this. I guess I'll just stick with Wine 5.6 then.
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #19 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Manuel from comment #18)
I don't get any error window. Also no crash dump in "Temp". The game just does not start. Client disappears for a few seconds and then reappears with the "Reconnect" button.
So maybe a different error but I can't debug this. I guess I'll just stick with Wine 5.6 then.
Hello,
That's exactly the state of the game for me since 4.8, using the 32-bit vsyscall workaround variant (I haven't tried the glibc workaround).
https://bugs.winehq.org/show_bug.cgi?id=47198#c54
I was once told that every League of Legends issue was known and that my issue was a dupe or something I missed, but no combination of the existing staging/workarounds/hacks did make it work past that for me. It must be another issue but I gave up with debugging that game myself. So maybe you want to file a new bug report for that.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49412
Alexis Peypelut iroalexis@outlook.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iroalexis@outlook.fr
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #20 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 70530 --> https://bugs.winehq.org/attachment.cgi?id=70530 Restore original Staging 32 bit syscall thunks format
(In reply to Paul Gofman from comment #13)
Created attachment 67750 [details] Restore original Staging 32 bit syscall thunks format
Does this patch on top of current Staging change anything (this supersedes the previous patch from Comment #9 but again all the other custom patches which were required prior to 5.9 are still needed. Could you please also make sure that you are building PE dlls with mingw (e. g., that you have ntdll.dll and ntdll.so and not ntdll.dll.so in the built Wine)?
Hi Paul!
After a long time (since version 6.5), I decided to give this a try again (I read there have been some wow/syscall improvements the last couple of months). It seems that the second (unidentified) bug that prevented the game from starting when using your patch has been fixed.
Now i can start a game using wine + staging (6.15) + alternative_patch_by_using_a_fake_cs_segment (Bug 47198) + a modified version (attached) of your second patch (I'm just using the "import.c" changes).
If starting from the console (without login-in to the game), a working setup shows a window saying that I'm "starting the game in a unsupported way".
Without your second patch, no window is shown, and the console prints: ``` 0104:err:virtual:virtual_setup_exception stack overflow 644 bytes in thread 0104 addr (nil) stack 0x36b0d7c (0x36b0000-0x36b1000-0x37b0000) ```
This stack overflow comes after a lot (736) "EXCEPTION_ACCESS_VIOLATION", as shown on the "seh" trace ``` 0104:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00000000 ip=00000000 tid=0104 0104:trace:seh:dispatch_exception info[0]=00000000 0104:trace:seh:dispatch_exception info[1]=00000000 0104:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0104:trace:seh:dispatch_exception eax=036b3ecc ebx=036b41e8 ecx=00000000 edx=7bc517c0 esi=036b3f04 edi=037aed40 0104:trace:seh:dispatch_exception ebp=036b3e58 esp=036b3e2c cs=0107 ds=002b es=002b fs=0063 gs=006b flags=00010212 0104:trace:seh:call_vectored_handlers calling handler at 100ECFC0 code=c0000005 flags=0 0104:trace:seh:call_vectored_handlers handler at 100ECFC0 returned 0 0104:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00000000 ip=00000000 tid=0104 0104:trace:seh:dispatch_exception info[0]=00000000 0104:trace:seh:dispatch_exception info[1]=00000000 0104:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0104:trace:seh:dispatch_exception eax=036b394c ebx=036b3c68 ecx=00000000 edx=7bc517c0 esi=036b3984 edi=037aed40 0104:trace:seh:dispatch_exception ebp=036b38d8 esp=036b38ac cs=0107 ds=002b es=002b fs=0063 gs=006b flags=00010216 0104:trace:seh:call_vectored_handlers calling handler at 100ECFC0 code=c0000005 flags=0 0104:trace:seh:call_vectored_handlers handler at 100ECFC0 returned 0 0104:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00000000 ip=00000000 tid=0104 0104:trace:seh:dispatch_exception info[0]=00000000 0104:trace:seh:dispatch_exception info[1]=00000000 0104:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0104:trace:seh:dispatch_exception eax=036b33cc ebx=036b36e8 ecx=00000000 edx=7bc517c0 esi=036b3404 edi=037aed40 0104:trace:seh:dispatch_exception ebp=036b3358 esp=036b332c cs=0107 ds=002b es=002b fs=0063 gs=006b flags=00010212 0104:trace:seh:call_vectored_handlers calling handler at 100ECFC0 code=c0000005 flags=0 0104:trace:seh:call_vectored_handlers handler at 100ECFC0 returned 0 0104:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00000000 ip=00000000 tid=0104 0104:trace:seh:dispatch_exception info[0]=00000000 0104:trace:seh:dispatch_exception info[1]=00000000 0104:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0104:trace:seh:dispatch_exception eax=036b2e4c ebx=036b3168 ecx=00000000 edx=7bc517c0 esi=036b2e84 edi=037aed40 0104:trace:seh:dispatch_exception ebp=036b2dd8 esp=036b2dac cs=0107 ds=002b es=002b fs=0063 gs=006b flags=00010216 0104:trace:seh:call_vectored_handlers calling handler at 100ECFC0 code=c0000005 flags=0 0104:trace:seh:call_vectored_handlers handler at 100ECFC0 returned 0 0104:trace:virtual:mprotect_exec forcing exec permission on 0x36b1000-0x36b1fff 0104:trace:virtual:mprotect_exec forcing exec permission on 0x36b1000-0x36b1fff 0104:trace:seh:dispatch_exception code=c00000fd flags=0 addr=7BC518F0 ip=7bc518f0 tid=0104 0104:trace:seh:dispatch_exception info[0]=00000001 0104:trace:seh:dispatch_exception info[1]=036b1ee8 0104:warn:seh:dispatch_exception EXCEPTION_STACK_OVERFLOW exception (code=c00000fd) raised 0104:trace:seh:dispatch_exception eax=7bc70904 ebx=036b2668 ecx=036b2374 edx=7bc517c0 esi=7bc70678 edi=037aed40 0104:trace:seh:dispatch_exception ebp=036b2368 esp=036b1ee0 cs=0107 ds=002b es=002b fs=0063 gs=006b flags=00010202 0104:trace:seh:call_vectored_handlers calling handler at 100ECFC0 code=c00000fd flags=0 0104:trace:seh:call_vectored_handlers handler at 100ECFC0 returned 0 0104:err:virtual:virtual_setup_exception stack overflow 1220 bytes in thread 0104 addr 0x7bc56b56 stack 0x36b0b3c (0x36b0000-0x36b1000-0x37b0000) ```
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #21 from Manuel mail+wine@m-reimer.de --- Is there any chance to make this work with the initial patch which worked with a patched glibc? I don't want to change a global setting (abi.vsyscall32) just for a game. For me it is much more convenient to install a separate, patched, glibc.
https://bugs.winehq.org/show_bug.cgi?id=49412
Josesk Volpe joseskvolpe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseskvolpe@gmail.com
--- Comment #22 from Josesk Volpe joseskvolpe@gmail.com --- Tried it on wine-staging 6.23. Without the patches, i still have the same stackoverflow error, but with different entries
0ac4:err:virtual:virtual_setup_exception stack overflow 964 bytes in thread 0ac4 addr (nil) stack 0x37c0c3c (0x37c0000-0x37c1000-0x38c0000)
The current patch for syscall is incompatible with this version
https://bugs.winehq.org/show_bug.cgi?id=49412
GloriousEggroll@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |GloriousEggroll@gmail.com
--- Comment #23 from GloriousEggroll@gmail.com --- Created attachment 71717 --> https://bugs.winehq.org/attachment.cgi?id=71717 updated syscall patch
Here is an updated version of the syscall patch from https://bugs.winehq.org/show_bug.cgi?id=49412#c20
I currently have LoL working on wine 7.0 + staging using the following patches/changes in order:
1. Apply staging:
../wine-staging/patches/patchinstall.sh DESTDIR="." --all
2. Apply the attached syscall patch
3. Apply rebased 'Alternative patch by using a fake cs segment' patch from: https://bugs.winehq.org/show_bug.cgi?id=47198#c107
4. Apply LoL client update failure fix patch from: https://bugs.winehq.org/show_bug.cgi?id=51687#c6
5. Apply (new) ws2_32 patch for more reliable client interface connectivity/functionality. Without this patch sometimes either the riot client fails to load "my games' section due to a connectivity error, or sometimes the league client itself fails to connect after logging in. With this patch I was able to connect reliably every time:
https://github.com/alesliehughes/alesliehughes-wine-staging/tree/master/patc...
6. The main issue is LoL needs a 5 minute wait script while it waits for a port to open, and needs abi.vsyscall32=0. The below 'launchhelper.sh' script is used in lutris. It calls the syscall_check.sh first to make sure abi.vsyscall32=0 is set and promps the user if not. Then it performs the 5 minute wait loop while waiting for the League Client's port to open:
https://lutris.nyc3.digitaloceanspaces.com/games/league-of-legend/launchhelp... https://lutris.nyc3.digitaloceanspaces.com/games/league-of-legend/syscall_ch...
The script requires zenity for the vsyscall check prompts and openssl for the port check.
Details on why the "wait-for-port-to-open" launchhelper.sh script is needed are as noted:
https://www.reddit.com/r/leagueoflinux/comments/j07yrg/starting_the_client_s...
"the gist is that the LeagueClientUx tries to wait for an SSL response on a port opened by the parent process. However, with the latest update, the parent process takes forever to open that port (~2m), so that the LeagueClientUx hits a timeout (~1m). The simple fix is to just suspend the LeagueClientUx process until that port responds, so I wrote a little script for that."
7. (optional) If using Garena (with DXVK), the Garena client needs vulkan childwindow patches from here to prevent rendering a black screen (posting sources for reference):
https://bugs.winehq.org/show_bug.cgi?id=45277#attach_70100
However they needed to be rebased onto 7.0 release, which the author has done here: https://github.com/rbernon/wine/commits/wip/vulkan-child/v1
Then lastly, this also needed to be rebased on top of staging (only minor changes luckily), which I've done here:
https://github.com/GloriousEggroll/wine-ge-custom/blob/master/patches/wine-h...
8. (optional) If using Garena, you also need to install vcrun2013 via winetricks, otherwise you will hit:
https://bugs.winehq.org/show_bug.cgi?id=47375
wine: Call from 7B0110C6 to unimplemented function msvcr120.dll.?_Schedule@_StructuredTaskCollection@details@Concurrency@@QAEXPAV_UnrealizedChore@23@@Z, aborting
Some additional notes:
I add a few performance related patches ported over from proton to my build, which can be found in the following script:
https://github.com/GloriousEggroll/wine-ge-custom/blob/master/patches/proton...
** For clarification, the following is the issue **: ------------ Without the port wait script, when you launch LoL from the Riot launcher, the "League of Legends" splash logo will come up for a period of time, then die and fall back to the Riot launcher.
The reason this happens has been clarified from the reddit post noted above:
"the LeagueClientUx tries to wait for an SSL response on a port opened by the parent process. However, with the latest update, the parent process takes forever to open that port (~2m), so that the LeagueClientUx hits a timeout (~1m)."
Ex.:
$ pidof LeagueClientUx.exe 33185
$ xargs -0 < /proc/33185/cmdline | sed -n 's/.*--app-port=([[:digit:]]*).*/\1/p' 41563
So now we spam checking waiting for the port to open with openssl, this is what takes a very long time:
$ openssl s_client -connect :41563 <<< Q 140003742518720:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 140003742518720:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: 140003742518720:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 140003742518720:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: connect:errno=111
$ openssl s_client -connect :41563 <<< Q 140101605764544:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 140101605764544:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: 140101605764544:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 140101605764544:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: connect:errno=111
$ openssl s_client -connect :41563 <<< Q 139781517258176:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 139781517258176:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: 139781517258176:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110: 139781517258176:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111: connect:errno=111
Until finally:
$ openssl s_client -connect :41563 <<< Q ... CONNECTED(00000003) depth=1 C = US, ST = California, L = Santa Monica, O = Riot Games, OU = LoL Game Engineering, CN = LoL Game Engineering Certificate Authority, emailAddress = gametechnologies@riotgames.com verify error:num=19:self signed certificate in certificate chain verify return:1 depth=1 C = US, ST = California, L = Santa Monica, O = Riot Games, OU = LoL Game Engineering, CN = LoL Game Engineering Certificate Authority, emailAddress = gametechnologies@riotgames.com verify return:1 depth=0 CN = rclient verify return:1 ...
$ netstat -neopa | grep -i 41563 | grep -i listen tcp 0 0 127.0.0.1:41563 0.0.0.0:* LISTEN 1000 263958 31029/wineserver off (0.00/0/0) ------------
** In case someone wants to assist with debugging the port issue without going through the patching hassle, the entire pre-patched wine branch can be found here, ready to compile**: ------------ https://github.com/gloriouseggroll/wine/tree/ge-7.0-1-lol
Just compile it then use it alongside DXVK when running the Riot Launcher and you should be able to reproduce the issue. ------------
https://bugs.winehq.org/show_bug.cgi?id=49412
--- Comment #24 from GloriousEggroll@gmail.com --- Additional note:
LoL uses a 32 bit client, so you will need to make sure you have both 64 and 32 bit graphic drivers installed.
https://bugs.winehq.org/show_bug.cgi?id=49412
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=49412
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #25 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Hi!. Since the 13.7 version, League of Legends uses a 64-bit game client, and so the 32-bit thunks changes are no longer required. I'm closing this since the new client has no problems with the 64-bit thunks.
Now, the only bug that prevents the game from running is Bug 54800. There is also Bug 51687 that prevents the RiotClient from updating itself, and Bug 54793 (from LeagueClient) with has a known workaround.
https://bugs.winehq.org/show_bug.cgi?id=49412
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #26 from Gijs Vermeulen gijsvrm@gmail.com --- Closing.
-
WineHQ Bugzilla