https://bugs.winehq.org/show_bug.cgi?id=47198
Bug ID: 47198 Summary: League of Legends 9.10 Crash after champ select Product: Wine Version: 4.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: composizion3@hotmail.com Distribution: ---
Created attachment 64453 --> https://bugs.winehq.org/attachment.cgi?id=64453 Console output.
9.10 patch broke the game on Linux; again; it crashes at the game start. It should also be noted that it is the patch that officially ended win xp/vista support.
https://bugs.winehq.org/show_bug.cgi?id=47198
kaito.linux@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaito.linux@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
Alan Dias alandms123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alandms123@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
starshine.dust@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |starshine.dust@gmx.de
https://bugs.winehq.org/show_bug.cgi?id=47198
popovicm7@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |popovicm7@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
atbjyk akihiroyamaguchi1208@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |akihiroyamaguchi1208@gmail. | |com
--- Comment #1 from atbjyk akihiroyamaguchi1208@gmail.com --- league of legends runs on staging only. so i think it's staging bug.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jack jack.howell@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jack.howell@protonmail.com
--- Comment #2 from Jack jack.howell@protonmail.com --- Hi folks
It is this patch that is at fault
https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Syste...
Needs more elaborate implementation.
https://bugs.winehq.org/show_bug.cgi?id=47198
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- (In reply to Jack from comment #2)
Hi folks
It is this patch that is at fault
https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll- SystemExtendedProcessInformation/0001-ntdll-Add-stub-for- NtQuerySystemInformation-SystemEx.patch
Needs more elaborate implementation.
On what grounds are you making this diagnosis? The console output alone is not enough to tell you that.
(In reply to atbjyk from comment #1)
league of legends runs on staging only. so i think it's staging bug.
I'd prefer to keep this to the Wine product; we reserve the Wine-Staging product for bugs that are introduced by Staging patches, i.e. applications which work in Wine but not in Wine-Staging.
https://bugs.winehq.org/show_bug.cgi?id=47198
marnap@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marnap@gmx.de
--- Comment #4 from marnap@gmx.de --- Created attachment 64455 --> https://bugs.winehq.org/attachment.cgi?id=64455 Winedbg output for tutorial start
Can confirm the game consistently crashing for me with Win 7 setting using wine-staging 4.8 and LoL 9.10.
I included a winedbg output, Leagues own crash logs do not seem helpful (i did only browse through them for a bit though).
The unhandled page fault does not seem to be related (most likely it is BugSplat crashing while trying to create a crash report?!).
I admit that i do not know winedbg, LoL or CEF well enough to know how to attach to the right process (or how) so i could get a backtrace.
https://bugs.winehq.org/show_bug.cgi?id=47198
sebastiaandingemans@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastiaandingemans@gmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=47198
electricryanyt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |electricryanyt@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
Lucas Amador lucasamadorzcv@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lucasamadorzcv@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
Debucquoy Anthony minecraftonitch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |minecraftonitch@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
nyikoszoltan0@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nyikoszoltan0@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
andris.laduzans@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andris.laduzans@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
turtle@bazon.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |turtle@bazon.ru
--- Comment #5 from turtle@bazon.ru --- Also can config 9.10, wine-staging 4.8 not works with wine7, wine8.1 configurations.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #6 from turtle@bazon.ru --- (In reply to turtle from comment #5)
Also can config 9.10, wine-staging 4.8 not works with wine7, wine8.1 configurations.
*can confirm*
https://bugs.winehq.org/show_bug.cgi?id=47198
winehq@smichel.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@smichel.me
https://bugs.winehq.org/show_bug.cgi?id=47198
aguertin+wine@aguertin.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aguertin+wine@aguertin.net
https://bugs.winehq.org/show_bug.cgi?id=47198
Majora320 majora320@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |majora320@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
2027342@tuta.io changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |2027342@tuta.io
https://bugs.winehq.org/show_bug.cgi?id=47198
vins_78@msn.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vins_78@msn.com
--- Comment #7 from vins_78@msn.com --- Bonjour,
Same issue with Ubuntu 18.04.2 LTS andexperimental D9VK on Lutris.
i'm so desesperate !!
https://bugs.winehq.org/show_bug.cgi?id=47198
Max maxjoehnk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maxjoehnk@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
Jaume Delclòs jaume@delclos.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaume@delclos.com
https://bugs.winehq.org/show_bug.cgi?id=47198
changhc84@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |changhc84@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #8 from Martin marnap@gmx.de --- Created attachment 64467 --> https://bugs.winehq.org/attachment.cgi?id=64467 LeagueClientUx.exe crash winedbg output
I tried pinpointing the crash, but admittedly did not get very far.
LeagueClientUx.exe does seem like the most likely culprit, but that could be due to my limited understanding of how exactly the CEF or the game itself work.
I did include the backtrace for the crash, but i cannot make out anything that gives me a hint as to what exactly is causing it.
https://bugs.winehq.org/show_bug.cgi?id=47198
Loris lollinos@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lollinos@hotmail.com
--- Comment #9 from Loris lollinos@hotmail.com --- I confirm these bug days ago, before the 9.10 patch.
I'm with Debian Buster 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux and wine-staging-amd64 4.8~buster.
This is the windows error, it doesn't work with xp, 7, 8 and 10.
Unhandled exception: illegal instruction in 32-bit code (0x7e9299e0). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e9299e0 ESP:0032f1cc EBP:0032f1e8 EFLAGS:00010202( R- -- I - - - ) EAX:7e9299e0 EBX:0032f318 ECX:00000001 EDX:00000001 ESI:7ffd8000 EDI:00000000 Stack dump: 0x0032f1cc: 7e5d6b54 00000000 00000000 0032f740 0x0032f1dc: 0032f318 7ffd8000 00000000 0032f288 0x0032f1ec: 7e5d7a1f 7e9299e0 00000000 00000000 0x0032f1fc: 0032f740 00000000 00000001 00000000 0x0032f20c: ffffffff 00000000 0000f860 7e9299e0 0x0032f21c: 00000000 00000000 00000000 00000000 Backtrace: =>0 0x7e9299e0 svcctl_QueryServiceConfigEx+0x140() in advapi32 (0x0032f1e8) 1 0x00000001 (0x0032f288) 2 0x7e5d7c05 UnhookWindowsHookEx+0x854() in user32 (0x0032f558) 3 0x7e5d8061 CallMsgFilterW+0x40() in user32 (0x0032f598) 4 0x7e5c7380 IsDialogMessageW+0x6f() in user32 (0x0032f708) 5 0x7e5c7bca IsDialogMessageW+0x8b9() in user32 (0x0032f778) 6 0x7e5c7dcb DialogBoxParamW+0x8a() in user32 (0x0032f7b8) 7 0x0040ce67 EntryPoint+0xffffffff() in bssndrpt (0x0032f924) 8 0x00403c3b EntryPoint+0xffffffff() in bssndrpt (0x0032fe6c) 9 0x004028f0 EntryPoint+0xffffffff() in bssndrpt (0x0032fe74) 10 0x00423731 in bssndrpt (+0x23730) (0x0032fec0) 11 0x7b4808f9 call_process_entry+0x18() in kernel32 (0x0032fee8) 12 0x7b483678 ExitProcess+0x2d6b() in kernel32 (0x0032ffd8) 13 0x7b48090a call_process_entry+0x29() in kernel32 (0x0032ffec) 0x7e9299e0 svcctl_QueryServiceConfigEx+0x140 in advapi32: Modules: Module Address Debug info Name (122 modules) PE 400000- 453000 Export bssndrpt PE 570000- 3bb1000 Deferred league of legends PE 10000000-10030000 Deferred bugsplatrc ELF 7ab38000-7ab66000 Deferred iphlpapi<elf> -PE 7ab40000-7ab66000 \ iphlpapi ELF 7ac00000-7b400000 Deferred libgtk-3.so.0 ELF 7b400000-7b846000 Dwarf kernel32<elf> -PE 7b430000-7b846000 \ kernel32 ELF 7bb1d000-7bc00000 Deferred libgcrypt.so.20 ELF 7bc00000-7bd75000 Deferred ntdll<elf> -PE 7bc30000-7bd75000 \ ntdll ELF 7bde7000-7be0c000 Deferred libgpg-error.so.0 ELF 7be0c000-7be2c000 Deferred liblz4.so.1 ELF 7be2c000-7be58000 Deferred liblzma.so.5 ELF 7be58000-7be62000 Deferred libdatrie.so.1 ELF 7be62000-7bec0000 Deferred libblkid.so.1 ELF 7bec0000-7bf6b000 Deferred libsystemd.so.0 ELF 7bf6b000-7bfe4000 Deferred libpcre.so.3 ELF 7bfe4000-7c000000 Deferred libfribidi.so.0 ELF 7c000000-7c005000 Deferred <wine-loader> ELF 7c00d000-7c019000 Deferred libthai.so.0 ELF 7c019000-7c047000 Deferred libgraphite2.so.3 ELF 7c047000-7c061000 Deferred libresolv.so.2 ELF 7c061000-7c08e000 Deferred libselinux.so.1 ELF 7c08e000-7c0fa000 Deferred libmount.so.1 ELF 7c0fa000-7c104000 Deferred libffi.so.6 ELF 7c104000-7c163000 Deferred libdbus-1.so.3 ELF 7c163000-7c213000 Deferred libpixman-1.so.0 ELF 7c213000-7c34c000 Deferred libglib-2.0.so.0 ELF 7c34c000-7c3b1000 Deferred libgobject-2.0.so.0 ELF 7c3b1000-7c400000 Deferred libpango-1.0.so.0 ELF 7c409000-7c43e000 Deferred libatspi.so.0 ELF 7c43e000-7c44d000 Deferred libxcb-render.so.0 ELF 7c44d000-7c452000 Deferred libxcb-shm.so.0 ELF 7c452000-7c46b000 Deferred libpangoft2-1.0.so.0 ELF 7c46b000-7c582000 Deferred libharfbuzz.so.0 ELF 7c582000-7c78a000 Deferred libgio-2.0.so.0 ELF 7c78a000-7c89c000 Deferred libepoxy.so.0 ELF 7c89c000-7c8ab000 Deferred libwayland-client.so.0 ELF 7c8ab000-7c8b4000 Deferred libwayland-cursor.so.0 ELF 7c8b4000-7c8fa000 Deferred libxkbcommon.so.0 ELF 7c8fa000-7c932000 Deferred libatk-bridge-2.0.so.0 ELF 7c932000-7ca82000 Deferred libcairo.so.2 ELF 7ca82000-7cb90000 Deferred libgdk-3.so.0 ELF 7cc12000-7cc17000 Deferred libwayland-egl.so.1 ELF 7cc17000-7cc40000 Deferred libatk-1.0.so.0 ELF 7cc40000-7cc6d000 Deferred libgdk_pixbuf-2.0.so.0 ELF 7cc95000-7cce3000 Deferred uxtheme<elf> -PE 7cca0000-7cce3000 \ uxtheme ELF 7cce3000-7ccea000 Deferred libxfixes.so.3 ELF 7ccea000-7ccf7000 Deferred libxcursor.so.1 ELF 7ccf8000-7cd02000 Deferred libcairo-gobject.so.2 ELF 7cd02000-7cd07000 Deferred libxdamage.so.1 ELF 7cd07000-7cd17000 Deferred libpangocairo-1.0.so.0 ELF 7cd17000-7cd1d000 Deferred libgmodule-2.0.so.0 ELF 7cfa6000-7cfb0000 Deferred libuuid.so.1 ELF 7cfb0000-7cfeb000 Deferred libexpat.so.1 ELF 7cfeb000-7d038000 Deferred libfontconfig.so.1 ELF 7d038000-7d077000 Deferred libpng16.so.16 ELF 7d077000-7d13a000 Deferred libfreetype.so.6 ELF 7d13a000-7d14d000 Deferred libxi.so.6 ELF 7d14d000-7d15a000 Deferred libxrandr.so.2 ELF 7d15a000-7d166000 Deferred libxrender.so.1 ELF 7d166000-7d185000 Deferred libbsd.so.0 ELF 7d185000-7d1b3000 Deferred libxcb.so.1 ELF 7d1b3000-7d302000 Deferred libx11.so.6 ELF 7d302000-7d317000 Deferred libxext.so.6 ELF 7d33f000-7d3f4000 Deferred winex11<elf> -PE 7d360000-7d3f4000 \ winex11 ELF 7d3f4000-7d53e000 Deferred oleaut32<elf> -PE 7d420000-7d53e000 \ oleaut32 ELF 7d53e000-7d57a000 Deferred ws2_32<elf> -PE 7d550000-7d57a000 \ ws2_32 ELF 7d57a000-7d5a1000 Deferred imm32<elf> -PE 7d580000-7d5a1000 \ imm32 ELF 7d5a1000-7d5fc000 Deferred usp10<elf> -PE 7d5b0000-7d5fc000 \ usp10 ELF 7d5fc000-7d769000 Deferred comctl32<elf> -PE 7d620000-7d769000 \ comctl32 ELF 7d769000-7d8ea000 Deferred ole32<elf> -PE 7d7a0000-7d8ea000 \ ole32 ELF 7d8ea000-7d920000 Deferred shcore<elf> -PE 7d8f0000-7d920000 \ shcore ELF 7d920000-7e357000 Deferred shell32<elf> -PE 7d950000-7e357000 \ shell32 ELF 7e357000-7e3e7000 Deferred shlwapi<elf> -PE 7e370000-7e3e7000 \ shlwapi ELF 7e3e7000-7e413000 Deferred version<elf> -PE 7e3f0000-7e413000 \ version ELF 7e413000-7e565000 Deferred gdi32<elf> -PE 7e430000-7e565000 \ gdi32 ELF 7e565000-7e7a0000 Dwarf user32<elf> -PE 7e590000-7e7a0000 \ user32 ELF 7e7a0000-7e7dd000 Deferred mpr<elf> -PE 7e7b0000-7e7dd000 \ mpr ELF 7e7dd000-7e7fc000 Deferred libz.so.1 ELF 7e7ff000-7e806000 Deferred libxxf86vm.so.1 ELF 7e806000-7e824000 Deferred aclui<elf> -PE 7e810000-7e824000 \ aclui ELF 7e824000-7e8c6000 Deferred wininet<elf> -PE 7e840000-7e8c6000 \ wininet ELF 7e8c6000-7e95f000 Dwarf advapi32<elf> -PE 7e8e0000-7e95f000 \ advapi32 ELF 7e95f000-7ea05000 Deferred rpcrt4<elf> -PE 7e980000-7ea05000 \ rpcrt4 ELF 7ee7f000-7ee94000 Deferred libnss_files.so.2 ELF 7ee94000-7eeaf000 Deferred libnsl.so.1 ELF 7eeaf000-7eebd000 Deferred libnss_nis.so.2 ELF 7eebd000-7eec7000 Deferred libnss_compat.so.2 ELF 7eec7000-7efcd000 Deferred libm.so.6 ELF 7efcd000-7efd8000 Deferred librt.so.1 ELF 7efda000-7efde000 Deferred libxcomposite.so.1 ELF 7efde000-7efe3000 Deferred libxinerama.so.1 ELF 7efe3000-7efea000 Deferred libxdmcp.so.6 ELF 7efea000-7f000000 Deferred wow64cpu<elf> -PE 7eff0000-7f000000 \ wow64cpu ELF f7b13000-f7b19000 Deferred libdl.so.2 ELF f7b19000-f7cf7000 Deferred libc.so.6 ELF f7cf7000-f7d18000 Deferred libpthread.so.0 ELF f7d1b000-f7d20000 Deferred libxau.so.6 ELF f7d40000-f7f0a000 Dwarf libwine.so.1 ELF f7f0c000-f7f36000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000e services.exe [C:\windows\system32\services.exe] 00000022 0 0000001c 0 00000015 0 00000010 0 0000000f 0 00000011 plugplay.exe [C:\windows\system32\plugplay.exe] 00000019 0 00000018 0 00000012 0 00000013 explorer.exe [C:\windows\system32\explorer.exe /desktop] 00000028 0 00000027 0 00000026 0 00000014 0 0000001a winedevice.exe [C:\windows\system32\winedevice.exe] 0000001f 0 0000001e 0 0000001d 0 0000001b 0 00000020 winedevice.exe [C:\windows\system32\winedevice.exe] 00000025 0 00000024 0 00000023 0 00000021 0 0000002c LeagueClient.exe ["C:/Riot Games/League of Legends/RADS/projects/league_client/releases/0.0.0.201/deploy/LeagueClient.exe" "--release=0.0.0.171"] 000000eb 0 000000e5 0 000000e2 0 000000e0 0 000000dc 0 000000db 0 00000081 0 00000068 0 00000065 0 00000064 0 00000062 0 00000061 0 00000060 0 0000005f 0 0000005e 15 0000005d 0 0000005c 0 0000005b 0 0000005a 0 00000059 0 00000057 0 00000056 0 00000055 0 00000054 0 0000004e 0 0000004d 0 0000004c 0 0000004b 0 0000004a 0 00000049 0 00000048 0 00000047 0 00000046 0 00000045 0 00000044 0 00000043 0 00000042 0 00000041 0 00000040 0 0000003f 0 0000003e 0 0000003d 0 0000003c 0 0000003b 0 0000003a 0 00000039 0 00000038 0 00000037 0 00000036 0 00000035 0 00000034 0 00000033 0 00000032 0 00000031 0 00000030 0 0000002f 0 0000002e 0 0000002d 0 000000f5 (D) C:\Riot Games\League of Legends\RADS\projects\league_client\releases\0.0.0.201\deploy\BsSndRpt.exe ["BsSndRpt.exe" /i "C:\users\loris\Temp\BsSndRpt.ini" /dl] 000000f6 0 <== 000000f9 explorer.exe [C:\windows\system32\explorer.exe /desktop] 000000ff 0 000000fe 0 000000fb 0 000000fa 0 000000fc LeagueClientUx.exe ["C:/Riot Games/League of Legends/RADS/projects/league_client/releases/0.0.0.201/deploy/LeagueClientUx.exe" "--release=0.0.0.171" "--rads-product-directory=C:/Riot Games/League of Legends/RADS/solutions/league_client_sln/releases/0.0.0.171/deploy/" "--remoting-auth-token=15nGoKhKcCGNI2Rvd_bzbg" "--respawn-command=LeagueClient.exe" "--respawn-display-name=League of Legends" "--app-port=45733" "--install-directory=C:/Riot Games/League of Legends/" "--app-name=LeagueClient" "--ux-name=LeagueClientUx" "--ux-helper-name=LeagueClientUxHelper" "--log-dir=LeagueClient Logs" "--bugsplat-name=league_client_riotgames_com" "--bugsplat-platform-id=EUW1" "--app-log-file-path=C:/Riot Games/League of Legends/Logs/LeagueClient Logs/2019-05-15T21-31-06_44_LeagueClient.log" "--app-pid=44" "--no-proxy-server"] 000000fd 0 System information: Wine build: wine-4.8 (Staging) Platform: i386 Version: Windows XP Host system: Linux Host version: 4.19.0-4-amd64
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- Please stop posting new confirmations, backtraces, and logs. Unless you have a good understanding of the problem (and that means more than "this fixme is printed in the console so this function/Staging patch must be at fault") that is not going to help anything. It will take someone actually thoroughly debugging the problem to solve it.
https://bugs.winehq.org/show_bug.cgi?id=47198
Andrew Wesie awesie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |awesie@gmail.com
--- Comment #11 from Andrew Wesie awesie@gmail.com --- With a 32-bit Linux kernel, the most recent wine-staging packages, and OS version set to Windows 7, I was able to join a tutorial game.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jacob Hrbek werifGX@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |werifGX@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #12 from Loris lollinos@hotmail.com --- I'm able to play a custom game 5v5 with only bot too. Maybe something related about loading of other people?
https://bugs.winehq.org/show_bug.cgi?id=47198
nesr nesrecar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nesrecar@gmail.com
--- Comment #13 from nesr nesrecar@gmail.com --- (In reply to Loris from comment #12)
I'm able to play a custom game 5v5 with only bot too. Maybe something related about loading of other people?
I cannot confirm this behaviour, it crashes for me with native bot games too, same thing (tried many versions). What wine version did you use et cetera?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #14 from Loris lollinos@hotmail.com --- (In reply to nesr from comment #13)
(In reply to Loris from comment #12)
I'm able to play a custom game 5v5 with only bot too. Maybe something related about loading of other people?
I cannot confirm this behaviour, it crashes for me with native bot games too, same thing (tried many versions). What wine version did you use et cetera?
I'm with Debian Buster 4.19.0-4-amd64 x64, wine-staging-amd64 4.8~buster, Windows 7, server EUW. When i'm at home i can give you more details.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #15 from turtle@bazon.ru ---
I'm with Debian Buster 4.19.0-4-amd64 x64, wine-staging-amd64 4.8~buster, Windows 7, server EUW. When i'm at home i can give you more details.
Debian Buster, 5.1.1 x86_64, wine-staging 4.8 from winehq repo, win7, EUW - not working.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #16 from Andrew Wesie awesie@gmail.com --- Created attachment 64481 --> https://bugs.winehq.org/attachment.cgi?id=64481 Proof-of-concept fix for 64-bit Linux 1 of 2
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #17 from Andrew Wesie awesie@gmail.com --- Created attachment 64482 --> https://bugs.winehq.org/attachment.cgi?id=64482 Proof-of-concept fix for 64-bit Linux 2 of 2
Glibc patch required to expand reserved size at top of struct pthread.
https://bugs.winehq.org/show_bug.cgi?id=47198
mail+wine@m-reimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail+wine@m-reimer.de
--- Comment #18 from mail+wine@m-reimer.de --- Thanks for working at this one. The "FIXME" means that there is a chance to create a fix which works with unpatched glibc? I would try to resurrect my "wine-staging-lol" PKGBUILD. Do you think statically linking wine to a patched glibc would work?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #19 from Andrew Wesie awesie@gmail.com --- (In reply to mail+wine from comment #18)
Thanks for working at this one. The "FIXME" means that there is a chance to create a fix which works with unpatched glibc?
Maybe. I tried to think of some creative solutions, but patching glibc is the easiest and safest. I'm hoping other Wine developers have some ideas.
I would try to resurrect my "wine-staging-lol" PKGBUILD. Do you think statically linking wine to a patched glibc would work?
My guess is that statically linking is generally a poor idea because of all of the other system libraries. I think you should be able to compile a patched glibc and use it when compiling / running wine, e.g. https://stackoverflow.com/a/851229, though I haven't tested that.
https://bugs.winehq.org/show_bug.cgi?id=47198
maxime.chassagneux@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maxime.chassagneux@gmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #20 from mail+wine@m-reimer.de --- After 6 hours of trying several different things, I'm giving up on this.
Setting "--dynamic-linker" is a total fail. It allows only one path and there are two different paths needed for 64bit and 32bit build. As wine seems to build binaries for both platforms in one build run, this always causes me to get corrupted binaries.
So I tried to only set "--rpath". This can be given twice, so I was able to specify both paths (32bit and 64bit) to my patched glibc. Compiles fine but throws segmentation fault when executed.
Patching my system main glibc is absolutely no option for me just to play LoL again.
If someone comes up with a working solution to link wine against some patched glibc, please post here so I can create working PKGBUILD's for Arch...
https://bugs.winehq.org/show_bug.cgi?id=47198
Michel Le Bihan michel@lebihan.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michel@lebihan.pl
--- Comment #21 from Michel Le Bihan michel@lebihan.pl --- Maybe `LD_PRELOAD=` can help with loading the patched glibc.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #22 from mail+wine@m-reimer.de --- It actually does at least to launch the game.
Preloading "libpthread.so" (32bit variant) does the trick.
I had a look at the (pre-) installed files and found this:
[manuel@manuelspc loader]$ ldd wine64 linux-vdso.so.1 (0x00007ffd36be6000) libwine.so.1 => /home/manuel/git/wine-lol/src/wine-lol-64-build/loader/./../libs/wine/libwine.so.1 (0x00007ff2c827e000) libpthread.so.0 => /usr/wine-lol-glibc/lib/libpthread.so.0 (0x00007ff2c825d000) libc.so.6 => /usr/wine-lol-glibc/lib/libc.so.6 (0x00007ff2c809a000) libdl.so.2 => /usr/wine-lol-glibc/lib/libdl.so.2 (0x00007ff2c8095000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff2c8443000) [manuel@manuelspc loader]$ ldd wine64-installed linux-vdso.so.1 (0x00007ffeaa172000) libwine.so.1 => /usr/lib/libwine.so.1 (0x00007f622bd92000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f622bd71000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f622bbac000) libdl.so.2 => /usr/wine-lol-glibc/lib/libdl.so.2 (0x00007f622bba7000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f622bf57000) [manuel@manuelspc loader]$ ldd wine64-preloader not a dynamic executable
So the built "wine64" is all OK. Just the path to libwine is screwed up.
Then "somewhere" and "somehow" a "wine64-installed" is created which has all my hard work (getting glibc in there somehow) removed again.
Who creates this "-installed" variant and how do I stop whatever is doing this from doing what it does?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #23 from mail+wine@m-reimer.de --- Wine adds a "--rpath,$ORIGIN" to the start of the compile/linking command. So I'll have to hack into there to get my glibc path in front of that...
Will have another look into this later this evening but now it seems to be solveable again.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #24 from mail+wine@m-reimer.de --- I've created a separate bug for the "rpath" issue: https://bugs.winehq.org/show_bug.cgi?id=47218 "Fixed" version still compiles...
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #25 from mail+wine@m-reimer.de --- Works now:
https://github.com/M-Reimer/wine-lol https://github.com/M-Reimer/wine-lol-glibc
https://aur.archlinux.org/packages/wine-lol https://aur.archlinux.org/packages/wine-lol-glibc
But I'm still hoping someone will find a fix which doesn't require glibc patching, so the fix can find its way into wine-staging.
https://bugs.winehq.org/show_bug.cgi?id=47198
ali.aziritobi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ali.aziritobi@gmail.com
--- Comment #26 from ali.aziritobi@gmail.com --- Thank you for fixing this. But can you explain to a noob how i can use these files to make the game run now ? I use Playonlinux for instance.Would be great if somebody explains me how i can make the game run
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #27 from Michele Renosto composizion3@hotmail.com --- Does the game still crashes for someone else half of the times even with the fixes?
(In reply to ali.aziritobi from comment #26)
Thank you for fixing this. But can you explain to a noob how i can use these files to make the game run now ? I use Playonlinux for instance.Would be great if somebody explains me how i can make the game run
You need to compile glibc and wine-staging with these patches. Ask on your distribution forums for how to do it.(In reply to ali.aziritobi from comment #26)
https://bugs.winehq.org/show_bug.cgi?id=47198
Andrew Dieffenbach puzzud@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |puzzud@gmail.com
--- Comment #28 from Andrew Dieffenbach puzzud@gmail.com --- (In reply to Michele Renosto from comment #27)
Does the game still crashes for someone else half of the times even with the fixes?
If it means anything, where the game started to unconditionally crash, prior to such, the game had been crashing often for me, but I wouldn't put it anywhere near the 50% mark.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #29 from mail+wine@m-reimer.de --- For me it's also not 100% stable.
I can start the game client and I can play all game modes.
But from time to time (often after one game completely finished and I want to join a second one) I get the crashes again.
In this case I have to get sure that *all* wine processes are gone. If I restart League after that, I can rejoin the game where I was thrown out by the crash.
This is OK and better than no solution at all. I'm not a that regular League player and TBH I just keep loosing my lanes :P
Would be interesting to get some deeper insight into this issue. Why does using "seccomp" have any impact here? Is this just an attempt to block some stuff that is done by League?
Why is this "memory expansion" needed? Just to store some info? Would it be possible to just malloc the right amount of memory and then store the pointer to this memory into the pthread struct memory?
https://bugs.winehq.org/show_bug.cgi?id=47198
Dmitriy xomachiner@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xomachiner@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #30 from Andrew Wesie awesie@gmail.com --- (In reply to mail+wine from comment #29)
For me it's also not 100% stable.
Agreed. Just with practice modes I was able to reproduce at least one crash. I haven't debugged it enough yet to know if it is related to this issue or something else. For me, the crash will happen right before I would normally see these lines in the output:
014b:fixme:process:NtQueryInformationProcess ProcessCookie (0xffffffff,0x10408c34,0x00000004,(nil)) stub 014b:fixme:ntdll:NtQuerySystemInformation SystemExtendedProcessInformation, len 1048576, buffer 0x3c64020, stub!
So I'm going to have to look closer at where NtQueryInformationProcess is getting called.
Would be interesting to get some deeper insight into this issue. Why does using "seccomp" have any impact here? Is this just an attempt to block some stuff that is done by League?
There are many ways to do a system call on Windows. LoL now does it in one of the more annoying ways for Wine to properly emulate.
Why is this "memory expansion" needed? Just to store some info? Would it be possible to just malloc the right amount of memory and then store the pointer to this memory into the pthread struct memory?
This is similar to some other issues that Wine has on other platforms / architectures. I suggest reading this question: https://stackoverflow.com/questions/53244454/how-did-wine64-manage-to-handle.... We basically have the same issue now with glibc, so the patch reserves some extra space that can be used by Wine without interfering with glibc's use of %gs.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #31 from aguertin+wine@aguertin.net --- If it helps anyone track this down faster, you do not need to be logged in to reproduce this crash. Simply running C:\Riot Games\League of Legends\Game\League of Legends.exe is enough.
(If the LoL bugsplat dialog appears, the crash did not reproduce. If the wine "System Error" dialog appears, the crash did reproduce. It is about 50-50 for me right now).
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #32 from mail+wine@m-reimer.de --- So if I understand correctly, then the "Windows binary" somewhat decides on its own where to read this information?
That's bad. I think this would mean this patch has bad chances to get staged.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #33 from Andrew Wesie awesie@gmail.com --- The instability is due to a typo in my fix for #45667. (info->VirtualAttributes.Valid in dlls/ntdll/virtual.c should be p->VirtualAttributes.Valid)
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #34 from aguertin+wine@aguertin.net --- Confirmed that with attachment 64496 from bug 45667, in addition to the patches in comment 16 and comment 17 of this bug, it works 100% of the time.
https://bugs.winehq.org/show_bug.cgi?id=47198
Denilson dsfeitosa10@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dsfeitosa10@gmail.com
--- Comment #35 from Denilson dsfeitosa10@gmail.com --- I am new to this linux universe, and have been facing this bug several times. Can anyone explain to me how to apply these fixes? I'm using PlayOnLinux (linux mint 19.1).
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #36 from mail+wine@m-reimer.de --- @Andrew Wesie If in the end it points out that the only realistic fix is to modify glibc: Do you think you can ask them to apply your patch upstream? At least in theory it should be easier in the "Open Source world" to get something like this fixed. At least easier than on Mac OS...
https://bugs.winehq.org/show_bug.cgi?id=47198
cristobal avila krizth2307@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krizth2307@gmail.com
--- Comment #37 from cristobal avila krizth2307@gmail.com --- (In reply to mail+wine from comment #25)
Works now:
https://github.com/M-Reimer/wine-lol https://github.com/M-Reimer/wine-lol-glibc
https://aur.archlinux.org/packages/wine-lol https://aur.archlinux.org/packages/wine-lol-glibc
But I'm still hoping someone will find a fix which doesn't require glibc patching, so the fix can find its way into wine-staging.
how to compile this in fedora?
https://bugs.winehq.org/show_bug.cgi?id=47198
fragment fragment137@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fragment137@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #38 from Fabian Maurer dark.shadow4@web.de ---
how to compile this in fedora?
Please keep the bugtracker on topic, for such questions the forums are a better place.
https://bugs.winehq.org/show_bug.cgi?id=47198
r.weclawski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |r.weclawski@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #39 from Andrew Wesie awesie@gmail.com --- Created attachment 64507 --> https://bugs.winehq.org/attachment.cgi?id=64507 Alternative patch by using a fake cs segment
This patch is better than the previous ones because it is simpler and does not require patching libc. It is also worse than the previous ones because it is more of a hack and moves us further away from a real Windows environment.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #40 from Andrew Wesie awesie@gmail.com --- (In reply to Andrew Wesie from comment #39)
This patch is better than the previous ones because it is simpler and does not require patching libc. It is also worse than the previous ones because it is more of a hack and moves us further away from a real Windows environment.
I forgot to mention that the alternative patch may require users to disable vdso32 via echo 0 > /proc/sys/abi/vsyscall32. This is because sysenter / syscall do not restore the %cs selector, but reset it to the default value.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #41 from turtle@bazon.ru ---
I forgot to mention that the alternative patch may require users to disable vdso32 via echo 0 > /proc/sys/abi/vsyscall32. This is because sysenter / syscall do not restore the %cs selector, but reset it to the default value.
with disabled vsyscall32 and without patching glibc works with alternative patch on debian buster. Later will check on debian stretch.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #42 from mail+wine@m-reimer.de --- (In reply to Andrew Wesie from comment #39)
This patch is better than the previous ones because it is simpler and does not require patching libc. It is also worse than the previous ones because it is more of a hack and moves us further away from a real Windows environment.
So in other words: There are good reasons to have this change in glibc?
If so then: a) would it be good to have this modified by the glibc developers? b) could you maybe mail them? I could offer to do so, but I won't be able to answer any of their questions...
I will stay with the "glibc patch" variant for now as I'm OK with the "separate glibc" approach.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #43 from turtle@bazon.ru --- (In reply to mail+wine from comment #42)
a) would it be good to have this modified by the glibc developers?
Even so there are will be long time before that changes was distributed to user OS.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #44 from mail+wine@m-reimer.de --- (In reply to turtle from comment #43)
Even so there are will be long time before that changes was distributed to user OS.
Of course.
But I guess there is a similar problem with the VDSO config change.
Distributors won't change this system wide just for Wine as, If I understand correctly, this could negatively affect 32 bit application performance.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #45 from Michel Le Bihan michel@lebihan.pl --- Created attachment 64508 --> https://bugs.winehq.org/attachment.cgi?id=64508 Font issue
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #46 from Michel Le Bihan michel@lebihan.pl --- With your latest patches (64507 and 64496) the game works works well and I never had it crash, but text in game is unreadable, especially on the HUD.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #47 from turtle@bazon.ru --- (In reply to mail+wine from comment #44)
(In reply to turtle from comment #43)
Even so there are will be long time before that changes was distributed to user OS.
Of course.
But I guess there is a similar problem with the VDSO config change.
Distributors won't change this system wide just for Wine as, If I understand correctly, this could negatively affect 32 bit application performance.
Yes, but every user can easily change it. Instead of patching glibc.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #48 from turtle@bazon.ru --- (In reply to Michel Le Bihan from comment #46)
With your latest patches (64507 and 64496) the game works works well and I never had it crash, but text in game is unreadable, especially on the HUD.
Can't confirm. May be because you build without any libraries? Freetype2, for example?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #49 from turtle@bazon.ru --- Created attachment 64510 --> https://bugs.winehq.org/attachment.cgi?id=64510 Fonts working
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #50 from mail+wine@m-reimer.de --- (In reply to turtle from comment #47)
Yes, but every user can easily change it. Instead of patching glibc.
Depends on how hard the performance hit actually is. I didn't try it, but I know that most of the games, I have in Steam, are 32 bit. Most of them are far more resource hungry than LoL.
But I think all this discussion doesn't really help to solve the problem. I'll do some work this weekend on my PKGBUILD and continue to watch this bug more in the background from now.
Big thanks to Andrew Wesie for his work to keep LoL running on Linux! This was a really fast solution to get the game working again!
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #51 from Michel Le Bihan michel@lebihan.pl --- Created attachment 64513 --> https://bugs.winehq.org/attachment.cgi?id=64513 configure log
I installed build dependencies. Configure isn't complaining about missing fonts.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #52 from Fabian Maurer dark.shadow4@web.de --- @Michel Le Bihan
Most likely not related to this bugreport, please keep it on topic.
@topic
For completeness, here a link to the wine-devel post for this issue: https://www.winehq.org/pipermail/wine-devel/2019-May/146014.html
https://bugs.winehq.org/show_bug.cgi?id=47198
Juan Carlos Carbajal Ipenza goesrex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |goesrex@gmail.com
--- Comment #53 from Juan Carlos Carbajal Ipenza goesrex@gmail.com --- When you disabled vsyscall32 works in debian stretch. Fonts works too.
https://bugs.winehq.org/show_bug.cgi?id=47198
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #54 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 64522 --> https://bugs.winehq.org/attachment.cgi?id=64522 terminal output with stack overflow using alternate fake cs register patch
Hello,
I'm still using Debian Jessie.
My prefix is 32-bit, my OS is 64-bit and I'm using wine-staging 4.8 (release tag) + patch from bug 45667 + alternative patch from comment 39 + vsyscall32 disabled.
While this prevents both wine and the game from showing their respective error dialogs, the tutorial match still doesn't start and the launcher comes back with the reconnect button.
The log shows a stack overflow of 192 bytes.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=47198
David Silva Villalobos epsilon2046@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |epsilon2046@gmail.com
--- Comment #55 from David Silva Villalobos epsilon2046@gmail.com --- What is the solution ?, I see that it is not even confirmed, I know that Riot does not do anything in Linux, but will it just stay that way ?, league of legends is played by new young people in Linux and I see that they propose solutions of difficulty, I am an Ubuntu user, should I know until the life of stallman and linus torvalds to be able to solve Linux problems?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #56 from Juan Carlos Carbajal Ipenza goesrex@gmail.com --- (In reply to David Silva Villalobos from comment #55)
What is the solution ?, I see that it is not even confirmed, I know that Riot does not do anything in Linux, but will it just stay that way ?, league of legends is played by new young people in Linux and I see that they propose solutions of difficulty, I am an Ubuntu user, should I know until the life of stallman and linus torvalds to be able to solve Linux problems?
This tutorial of how apply the patch (https://www.reddit.com/r/leagueoflinux/comments/936rce/how_to_apply_the_new_...) is very helpful. The only thing that I did different was do "./configure --enable-win64" in the step 3.
https://bugs.winehq.org/show_bug.cgi?id=47198
keifanel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |keifanel@gmail.com
--- Comment #57 from keifanel@gmail.com --- (In reply to Olivier F. R. Dierick from comment #54)
Created attachment 64522 [details] terminal output with stack overflow using alternate fake cs register patch
Hello,
I'm still using Debian Jessie.
My prefix is 32-bit, my OS is 64-bit and I'm using wine-staging 4.8 (release tag) + patch from bug 45667 + alternative patch from comment 39 + vsyscall32 disabled.
While this prevents both wine and the game from showing their respective error dialogs, the tutorial match still doesn't start and the launcher comes back with the reconnect button.
The log shows a stack overflow of 192 bytes.
Regards.
I'm getting basically the same output following tutorial from comment #56.
Ubuntu 19.04 64bit, wine configured with ./configure --enable-win64
https://bugs.winehq.org/show_bug.cgi?id=47198
João Carvalho jpldcarvalho@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpldcarvalho@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #58 from mail+wine@m-reimer.de --- On the mailing list, you mention that this is triggered by WoW64. There are also reports that everything kept working with a 32 bit kernel.
I've tried to build a 32 bit only wine in hope that this maybe also works around the problem, but it doesn't. Still crashes.
Do I really need a 32 bit kernel or is there some other way to build Wine so that LoL thinks it runs on a 32 bit only system?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #59 from Andrew Wesie awesie@gmail.com --- (In reply to mail+wine from comment #58)
Do I really need a 32 bit kernel or is there some other way to build Wine so that LoL thinks it runs on a 32 bit only system?
The detection of WoW64 is based on the %cs register. The default value of the cs segment selector is determined by the kernel, not user space, hence you need to have a 32-bit kernel if you want to run without any of these patches.
https://bugs.winehq.org/show_bug.cgi?id=47198
Samega 7Cattac 7Cattac@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |7Cattac@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rawfox@freenet.de
--- Comment #60 from rawfox rawfox@freenet.de --- Wonderfull :) The 2 patches + vsyscall32=0 made the game work again :) D9VK, vc2017, corefonts i had to throttle fps down to 60. Thanks for your work and lets hope it gets solved anyhow in the future^^
https://bugs.winehq.org/show_bug.cgi?id=47198
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
sebastiaandingemans@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sebastiaandingemans@gmail.c | |om |
https://bugs.winehq.org/show_bug.cgi?id=47198
RDL soft-sonic@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |soft-sonic@yandex.ru
--- Comment #61 from RDL soft-sonic@yandex.ru --- Alternate patch does not work if you use run game via optirun Can I fix this?
https://bugs.winehq.org/show_bug.cgi?id=47198
y6ep3 kwark87@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kwark87@gmail.com
--- Comment #62 from y6ep3 kwark87@gmail.com --- Hello! In both variants (glibc patch and alternate with disabled vsyscall32) didn't work hud in game, but before 9.9 all works well. May be somebody can give advise how to find reason?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #63 from y6ep3 kwark87@gmail.com --- So now it works good and HUD too. I use lutris league-of-legends-experimental-d9vk. But I had to add "arch": "win32" to json configuration manually in "game" and in task that install wine prefix. Additionally I had to fix UI lutris configuration (game path, wine prefix path, wine arch and system env variables). For runner I use wine-4.9 that patched by wine-staging-4.9 and patch from comment #39 with disabled vsyscall32 Thank all of you for your comments.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jontom Xire JontomXire@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |JontomXire@yahoo.co.uk
--- Comment #64 from Jontom Xire JontomXire@yahoo.co.uk --- I built wine following the tutorial and using the alternative patch only. I installed to /wine/patched. I exported PATH with /wine/patched/usr/local/bin as the first path. When I run wine64 (I used the --enable-64 when configuring) or winecfg, I get the following text on the terminal:
wine client error:0: version mismatch 586/584. Your wine binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running?
There are no wineservers running. Somehow it is detecting my older wine staging install.
How do I fix this without removing the "proper" wine install?
Various posts suggest that calling the wine binary with a full path should work, but it doesn't.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #65 from Jontom Xire JontomXire@yahoo.co.uk --- (In reply to Jontom Xire from comment #64)
Fixed it. I needed to set LD_LIBRARY_PATH too.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #66 from Jontom Xire JontomXire@yahoo.co.uk --- It still crashes at the same place. I cannot do the vsyscall32 thing:
sudo echo 0 > /proc/sys/abi/vsyscall32 bash: /proc/sys/abi/vsyscall32: Permission denied
It didn't prompt for a password as I had already used sudo recently.
I am on Ubuntu 18. I notice some people are applying a second patch too. Some aren't. Do I need it?
A little help would be greatly appreciated.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #67 from Juan Carlos Carbajal Ipenza goesrex@gmail.com --- (In reply to Jontom Xire from comment #66)
It still crashes at the same place. I cannot do the vsyscall32 thing:
sudo echo 0 > /proc/sys/abi/vsyscall32 bash: /proc/sys/abi/vsyscall32: Permission denied
It didn't prompt for a password as I had already used sudo recently.
I am on Ubuntu 18. I notice some people are applying a second patch too. Some aren't. Do I need it?
A little help would be greatly appreciated.
sudo su
And after:
echo 0 > /proc/sys/abi/vsyscall32
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #68 from Juan Carlos Carbajal Ipenza goesrex@gmail.com --- (In reply to Jontom Xire from comment #66)
It still crashes at the same place. I cannot do the vsyscall32 thing:
sudo echo 0 > /proc/sys/abi/vsyscall32 bash: /proc/sys/abi/vsyscall32: Permission denied
It didn't prompt for a password as I had already used sudo recently.
I am on Ubuntu 18. I notice some people are applying a second patch too. Some aren't. Do I need it?
A little help would be greatly appreciated.
sudo su
And after:
echo 0 > /proc/sys/abi/vsyscall32
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #69 from mail+wine@m-reimer.de --- Can't work that way as the output redirection still is done in context of your user.
I'll never understand the people that insist on writing "sudo" in front of every command.
Just get a proper root-shell with
sudo -i
and then enter the echo command without the sudo in front of it.
After doing your "root business", close the root-shell with "exit".
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #70 from Fabian Maurer dark.shadow4@web.de --- Please keep the bugtracker on topic, this is not the place for user support.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #71 from Jontom Xire JontomXire@yahoo.co.uk --- Sorry.
Where is the place for user support? It still crashes even after I disable VDSO32.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #72 from mail+wine@m-reimer.de --- You could try to get support here:
https://www.reddit.com/r/leagueoflinux/
But as far as I know the "VDSO32" solution is not used that often. Most people go with some way of having a second glibc, with the required patch, besides the unmodified system glibc. You'll find some solutions by reading the first 5 to 10 threads on this subreddit.
https://bugs.winehq.org/show_bug.cgi?id=47198
Georgi Dichev kutalion@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kutalion@abv.bg
--- Comment #73 from Georgi Dichev kutalion@abv.bg --- To everyone having the no fonts problem. There is a simple solution: winetricks d3dx9
Wait for it to finish. Run LoL Client, click play, select game mode, click find match and crush your enemies ;)
https://bugs.winehq.org/show_bug.cgi?id=47198
noxa@atnextmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noxa@atnextmail.com
--- Comment #74 from noxa@atnextmail.com --- You can download <a href="https://pngpicture.com/league-of-legends-png/">League of Legends gifs</a> and watch it at the time of solving this error. This helps you to relax.
https://bugs.winehq.org/show_bug.cgi?id=47198
aligamerh47@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aligamerh47@gmail.com
--- Comment #75 from aligamerh47@gmail.com --- i'm wondering how is this still unconfirmed
https://bugs.winehq.org/show_bug.cgi?id=47198
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Christin.Weser@pwners.de
--- Comment #76 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 47423 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47198
Yuko Moraes Pereira yukovamp@icloud.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yukovamp@icloud.com
--- Comment #77 from Yuko Moraes Pereira yukovamp@icloud.com --- In Fedora 30 x86_64 I tested the latest wine + staging patches + Andrew patch for wine/dlls/ntdll/virtual.c changing "info->" for "p->" and the alternate fix patch (instead of custom glib) with echo 0 > /proc/sys/abi/vsyscall32
The game is working fine until now. I tested 5 vs bots and training. Strangely it is quicker than in windows.
Thanks for dedicating some of your time and knowledge to getting this game running again Andrew. Thanks to Juan for mentioning that tutorial.
Maybe I will test the custom glibc too later.
Obs: For those building their own wines, the first patch from bug 45667 was not needed, only the second I mentioned above. The source code was already fixed after the staging patches. The patch mentioned at the building wine tutorial above from 11 months ago was not needed either.
Obs2: To build wine first I patched, later I ran ./config --without-gtk3.
https://bugs.winehq.org/show_bug.cgi?id=47198
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matias.nicolas.zc@gmail.com
--- Comment #78 from Matías Zúñiga matias.nicolas.zc@gmail.com --- (In reply to Andrew Wesie from comment #39)
Created attachment 64507 [details] Alternative patch by using a fake cs segment
This patch is better than the previous ones because it is simpler and does not require patching libc. It is also worse than the previous ones because it is more of a hack and moves us further away from a real Windows environment.
Hi Andrew. By using your patch, League crashes on start. I can't read the dump file, because winegdb crashes with:
``` 00b3:fixme:dbghelp:addr_to_linear Failed to linearize address 1007:7e182621 (mode 1) home/Manizuca/.wine/drive_c/users/Manizuca/Temp/LeagueClientUxHelperCPDH7GT0.dmp: cpu_i386.c:278: i386_stack_walk: Assertion `curr_mode == stm_32bit' failed. winedbg: Internal crash at 0xf7f29112 ```
That crash happens only with dumps made with your patch applied, do you know how to fix that?
thanks
https://bugs.winehq.org/show_bug.cgi?id=47198
electricryanyt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|electricryanyt@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
David Mudrák david@mudrak.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@mudrak.name
--- Comment #79 from David Mudrák david@mudrak.name --- I can confirm that I was finally able to make this work on my son's Ubuntu 18.04 (64bit) machine with manually compiled wine-staging 4.14 + Andrew's patch from the comment #39 + the second patch from the bug 45667
I used https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu as a general guide on how to compile custom wine. On contrary to what that guide suggests, I had to have the default wine-staging package installed too (via apt) to get all the required dependencies present.
I have Windows 7 selected as the version in winecfg and I used winetricks to install dxvk, vcrun2017 and corefonts.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jorge Pinilla Lopez tarmabal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tarmabal@gmail.com
--- Comment #80 from Jorge Pinilla Lopez tarmabal@gmail.com --- With wine + staging + patch 64496 and 64507 is working perfectly.
I created a small repo with a PKGBUILD to build it:
https://github.com/jorpilo/wine-staging-lol
IDK if it would be interesting to set it up as an AUR for people to build it easily.
Is it better to fix it with the alternative patch or with the glib patch?
Thanks for dedicating so much time into this!
https://bugs.winehq.org/show_bug.cgi?id=47198
Vladyslav tsubervlad@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tsubervlad@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
jamesbuyacar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jamesbuyacar@gmail.com
--- Comment #81 from jamesbuyacar@gmail.com --- (In reply to Andrew Wesie from comment #39)
Created attachment 64507 [details] Alternative patch by using a fake cs segment
This patch is better than the previous ones because it is simpler and does not require patching libc. It is also worse than the previous ones because it is more of a hack and moves us further away from a real Windows environment.
this patch is working perfectly for me in wine-staging 4.15, but no longer applies cleanly on 4.16.
$ sudo cat `sudo find /var/tmp/portage/app-emulation/wine-staging-4.16 -name signal_i386.c.rej` --- dlls/ntdll/signal_i386.c +++ dlls/ntdll/signal_i386.c @@ -1578,7 +1580,7 @@ static inline DWORD is_privileged_instr( CONTEXT *context ) const BYTE *instr; unsigned int prefix_count = 0;
- if (!wine_ldt_is_system( context->SegCs )) return 0; + if (context->SegCs != wine_cs && !wine_ldt_is_system( context->SegCs )) return 0; instr = (BYTE *)context->Eip;
for (;;) switch(*instr)
I much prefer addressing the bug in wine as opposed to needing to manage a second patched glibc.
any chance of getting an updated patch into wine-staging?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #82 from RDL soft-sonic@yandex.ru --- After updating to 9.20, the game crashes again after choosing a champion.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #83 from mail+wine@m-reimer.de --- This bug is about the 9.10 issue only which has received working patches by Andrew Wesie which have been added to the most common solutions to play LoL on Linux.
I've created a new bug report for the current issue which came with the 9.20 update: https://bugs.winehq.org/show_bug.cgi?id=47915
https://bugs.winehq.org/show_bug.cgi?id=47198
Alex horatioesf@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |horatioesf@protonmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
juliansperling@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juliansperling@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #84 from jamesbuyacar@gmail.com --- Created attachment 65489 --> https://bugs.winehq.org/attachment.cgi?id=65489 post 4.15 no-VDSO patch
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #85 from RDL soft-sonic@yandex.ru --- tell us more about this patch, please
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #86 from jamesbuyacar@gmail.com --- (In reply to jamesbuyacar from comment #81)
(In reply to Andrew Wesie from comment #39)
Created attachment 64507 [details] Alternative patch by using a fake cs segment
making an attachment broke my reply. it's an update of this patch which no longer applies cleanly.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #87 from Manuel mail+wine@m-reimer.de --- Where is the correct point to add "Proof of concept fix 1 of 2" for Wine 4.20?
Again at the end of thread_init:
https://github.com/wine-mirror/wine/blob/master/dlls/ntdll/thread.c#L312
Or after the new place of the NtCreateKeyedEvent(...) call:
https://github.com/wine-mirror/wine/blob/master/dlls/ntdll/loader.c#L4257
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #88 from juliansperling@gmail.com --- Created attachment 65712 --> https://bugs.winehq.org/attachment.cgi?id=65712 4.20 PoC Patch Update Options
My attempt at updating the PoC Patch from comment #16 for 4.20.
I tried both Places suggested by comment #87, and since both work i included both versions. Only one of the two should be applied.
Patch1 is applied to thread.c and pretty much only needed the function call in thread_init to be reinserted
Patch2 moves everything to load.c instead of thread.c, where it was also missing uint64_t and uintptr_t so i had to add an import
Please Note: I am not a Dev. All I can say is that the Patches apply successfully, wine builds successfully and League of Legends works (past champ select).
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #89 from Manuel mail+wine@m-reimer.de --- So I guess it doesn't really matter where the call is inserted? Would be nice if a developer could tell which of the two options he would prefer from a technical standpoint. I would like to roll a new wine-lol build. Seems like we are down to just one patch to make LoL work. The two other patches found their way to wine-staging.
https://bugs.winehq.org/show_bug.cgi?id=47198
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=47198
David Torok dt@zeroitlab.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dt@zeroitlab.com
--- Comment #90 from David Torok dt@zeroitlab.com --- Created attachment 66212 --> https://bugs.winehq.org/attachment.cgi?id=66212 Patch that adds more elaborate stub for NtDebugActiveProcess
From what I see, there are 2 parts to this issue.
1. The direct syscall. We are missing the corresponding nt thunk, which is the root cause here. I've attached a patch above to correct that.
2. Reading from %gs. This is a tougher one to solve, here are a few options I'm thinking of, without changing glibc: - Virtualizing %gs access, by setting it to PROT_NONE and catching SIGSEGV and emulating the instructions like we do for KUSER_SHARED_DATA. The downside to this is probably speed; otherwise this is a viable path. (but I prefer not slowing down wine) - Allocating a proper windows %gs segment and changing %gs on transitions. We already have a similar issue on ARM in the form of x18 collisions. (bug 38780) We can either wait for upstream to solve that and basically adopt the same for x86 or make something like that on our own for staging. One caveat is that the x18 PoC patch forces relays on, which breaks syscall hooking in chrome and various other apps, so the final implementation has to be more precise with the code path than just forcing relays on. I don't have a PoC patch for this issue (yet).
https://bugs.winehq.org/show_bug.cgi?id=47198
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash@kolahilft.de
--- Comment #91 from kolAflash kolAflash@kolahilft.de --- Is there a compatible patch for Wine-Staging-5.6, so the vsyscall32 can still be used? (the old patch doesn't apply anymore)
https://bugs.winehq.org/show_bug.cgi?id=47198
w0lfwood jamesbuyacar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65489|0 |1 is obsolete| |
--- Comment #92 from w0lfwood jamesbuyacar@gmail.com --- Created attachment 66891 --> https://bugs.winehq.org/attachment.cgi?id=66891 vsyscall32 5.5
here is a vsyscall32 patch updated for wine 5.5. I'll post one for 5.6 once I've updated it.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #93 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 66892 --> https://bugs.winehq.org/attachment.cgi?id=66892 5.6-alternative_patch_by_using_a_fake_cs_segment
(In reply to kolAflash from comment #91)
Is there a compatible patch for Wine-Staging-5.6, so the vsyscall32 can still be used? (the old patch doesn't apply anymore)
This [0] is the patch i'm using for my fedora builds.
[0] https://copr-dist-git.fedorainfracloud.org/cgit/manizuca/wine-lol/wine.git/p...
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #94 from w0lfwood jamesbuyacar@gmail.com --- (In reply to Matías Zúñiga from comment #93)
Created attachment 66892 [details] 5.6-alternative_patch_by_using_a_fake_cs_segment
(In reply to kolAflash from comment #91)
Is there a compatible patch for Wine-Staging-5.6, so the vsyscall32 can still be used? (the old patch doesn't apply anymore)
This [0] is the patch i'm using for my fedora builds.
[0] https://copr-dist-git.fedorainfracloud.org/cgit/manizuca/wine-lol/wine.git/ plain/alternative_patch_by_using_a_fake_cs_segment.patch?h=f31
Thanks, this patch is working well for me for 5.6.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #95 from juliansperling@gmail.com --- Created attachment 67232 --> https://bugs.winehq.org/attachment.cgi?id=67232 Wine Patch glibc solution wine >= 5.9
Under Wine Staging Version 5.9 the old custom Patch no longer applies, this is the renewed version.
I can't validate that loading into game actually works since https://bugs.winehq.org/show_bug.cgi?id=49025 seems to persist in 5.9.
https://bugs.winehq.org/show_bug.cgi?id=47198
Simon the Sorcerer sur3@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sur3@gmx.de
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #96 from aguertin+wine@aguertin.net --- (In reply to juliansperling from comment #95)
Created attachment 67232 [details] Wine Patch glibc solution wine >= 5.9
Under Wine Staging Version 5.9 the old custom Patch no longer applies, this is the renewed version.
I can't validate that loading into game actually works since https://bugs.winehq.org/show_bug.cgi?id=49025 seems to persist in 5.9.
With Bug 49025 being fixed, I can confirm that this patch works with wine staging 5.9.
However, it will need another update for wine staging 5.10.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #97 from aguertin+wine@aguertin.net --- Created attachment 67430 --> https://bugs.winehq.org/attachment.cgi?id=67430 Patch (glibc version) for wine >= 5.10
Here is the patch for the glibc-based solution updated to wine 5.10. As a reminder, it also needs the glibc patch from comment 17.
I am not currently able to test it because of Bug 49373.
https://bugs.winehq.org/show_bug.cgi?id=47198
harry harry+winehq@unheit.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |harry+winehq@unheit.net
--- Comment #98 from harry harry+winehq@unheit.net --- Is ther any chance that will ever be supported in wine/wine-staging without custom patches? Until now, this bug report is still UNCONFIRMED.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #99 from nesr nesrecar@gmail.com --- (In reply to harry from comment #98)
Is ther any chance that will ever be supported in wine/wine-staging without custom patches? Until now, this bug report is still UNCONFIRMED.
That bug won't change the state, I believe. Riot announced some anti-cheat changes for 2021 which makes LoL unplayable under Linux anyway.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #100 from aguertin+wine@aguertin.net --- (In reply to harry from comment #98)
Is ther any chance that will ever be supported in wine/wine-staging without custom patches? Until now, this bug report is still UNCONFIRMED.
My impression is that since this bug is so heavily tied in to NTDLL, there's little chance of someone working on it while the work on creation of a Unix library for NTDLL is ongoing. Any work done here would have to get done and redone multiple times as the entire NTDLL codebase changes underneath it.
Lots of NTDLL-related wine-staging patches are disabled for this reason too. Here's a good recent example: https://github.com/wine-staging/wine-staging/commit/70d81789275c4c5b8fed0199...
"Fixing this would require a nontrivial amount of effort, which will be obviated as soon as Alexandre finishes splitting ntdll upstream."
I haven't seen any roadmap for the ntdll unix library work, but from my outsider's perspective I'd guess it's about 1/3 done. It started in mid-May, so maybe check back in October?
In the meantime, wine-5.6 with patches from here remains the easiest way to play, although with effort you can update to a patched version of wine-5.9.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #101 from Matías Zúñiga matias.nicolas.zc@gmail.com --- If the question is whether the patches here can be applied upstream, I think the answer is no, because the current solutions depend on having a customized glibc or disabling vdso32 at a kernel level. And probably nobody will try a different approach knowing that it will probably stop working with the 2021 changes
For now you can run league in wine 5.11 and 5.10 with the patches at Bug 49412 and wine 5.6 through 5.9 with the alternative patches here.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jaume Delclòs jaume@delclos.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jaume@delclos.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
Alexis Peypelut iroalexis@outlook.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iroalexis@outlook.fr
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #102 from David Torok dt@zeroitlab.com --- The NtDebugActiveProcess process part of the issue is now properly fixed by 46b84e7a83beae7484e6daac16739a2b9238f68e upstream.
Just a reminder, the remaining issue is: Allocating a proper windows %gs segment and changing %gs on transitions. We already have a similar issue on ARM in the form of x18 collisions. (bug 38780) We can either wait for upstream to solve that and basically adopt the same for x86 or make something like that on our own for staging.
Since syscalls are labeled with -syscall in the spec files, now it's even easier than before to make a hack for this using forced +relays. However, for a proper solution to exist, there has to be an interface between all unix and windows code where we can put thunks like this. There has been good progress on that front (having a distinct barrier), but it's not there yet.
Maybe it's desirable to close this issue in favor of splitting it into "Wow64: distinct barriers between unix and windows code" or something similar?
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #103 from Zebediah Figura z.figura12@gmail.com --- (In reply to David Torok from comment #102)
Maybe it's desirable to close this issue in favor of splitting it into "Wow64: distinct barriers between unix and windows code" or something similar?
Possibly, but I don't really like that title (consider: when is the bug fixed?) and there are multiple ways to fix this bug anyway.
https://bugs.winehq.org/show_bug.cgi?id=47198
RafaelKr coding@rafael.kr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |coding@rafael.kr
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #104 from Manuel mail+wine@m-reimer.de --- Can someone please update the patch
https://bugs.winehq.org/attachment.cgi?id=64481
to work with Wine 6.10? My try at this can be found here:
https://github.com/M-Reimer/wine-lol/blob/wine-6.10/wine-lol/wine-lol-bug-47...
And all I can get is a immediate "disappear" of the game window as soon as I try to start a game.
The "old" entry point "thread_init" is gone, so I had to find some alternative. But I'm not sure if my choice is OK.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #105 from Manuel mail+wine@m-reimer.de --- OK. Actually there is some chance that I run into this:
https://bugs.winehq.org/show_bug.cgi?id=49373
and my patch actually should do what it is supposed to do. So I guess I'll still be stuck with 5.6 for now.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #106 from Manuel mail+wine@m-reimer.de --- With the last update of the LoL client the Wine version, used so far, no longer is able to run the client. Most probably because they updated to CEF-91.
A up to date wine-staging can start the client but then will not allow to actually play the game. So this issue seems to have been fixed with later wine-staging versions.
I also tried with regular Wine (GIT-version from today) and this also fails to start the client. So whatever fixes this has to be a staging patch.
So maybe that's a good point where someone with the required knowledge could try to port the patches to a more modern Wine version?
The only alternative, I can think of, would be backporting whatever wine-staging patch is needed. But, so far, I haven't found the correct one and I'm not sure if backporting will be possible at all.
https://bugs.winehq.org/show_bug.cgi?id=47198
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66892|0 |1 is obsolete| |
--- Comment #107 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 70550 --> https://bugs.winehq.org/attachment.cgi?id=70550 Alternative patch by using a fake cs segment
(In reply to Manuel from comment #106)
With the last update of the LoL client the Wine version, used so far, no longer is able to run the client. Most probably because they updated to CEF-91.
A up to date wine-staging can start the client but then will not allow to actually play the game. So this issue seems to have been fixed with later wine-staging versions.
I also tried with regular Wine (GIT-version from today) and this also fails to start the client. So whatever fixes this has to be a staging patch.
So maybe that's a good point where someone with the required knowledge could try to port the patches to a more modern Wine version?
The only alternative, I can think of, would be backporting whatever wine-staging patch is needed. But, so far, I haven't found the correct one and I'm not sure if backporting will be possible at all.
As i commented recently in Bug 49412, I'm able to start a game using the last posted "Restore original Staging 32 bit syscall thunks format" patch, and the attached "Alternative patch by using a fake cs segment" patch.
Keep in mind that, while i can start the client and play a game, I can not update the riot client: "Update failed: Failed getting path to current executable: File path could not be found in a mapped drive: ??\C:\Riot Games\Riot Client\RiotClientServices.exe"... but that probably something not-so-difficult to fix if is a wine bug (and not something with my configuration), and someone has time to debug it.
https://bugs.winehq.org/show_bug.cgi?id=47198
changhc84@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|changhc84@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
nesr nesrecar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|nesrecar@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #108 from harry harry+winehq@unheit.net --- (In reply to Matías Zúñiga from comment #107)
Alternative patch by using a fake cs segment
It works! Using wine-staging 6.16, this patch and patch from https://bugs.winehq.org/show_bug.cgi?id=49412#c20.
Good job! Thanks a lot!
Keep in mind that, while i can start the client and play a game, I can not update the riot client: "Update failed: Failed getting path to current executable: File path could not be found in a mapped drive: ??\C:\Riot Games\Riot Client\RiotClientServices.exe"... but that probably something not-so-difficult to fix if is a wine bug (and not something with my configuration), and someone has time to debug it.
I did a fresh install without a problem. Since the client updates immediately after the install, and that worked, I assume that other updates should work, too. Didn't have another update since then, though.
harry
https://bugs.winehq.org/show_bug.cgi?id=47198
winehq.org@smichel.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|winehq.org@smichel.me |
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #109 from harry harry+winehq@unheit.net ---
Keep in mind that, while i can start the client and play a game, I can not update the riot client: "Update failed: Failed getting path to current executable: File path could not be found in a mapped drive: ??\C:\Riot Games\Riot Client\RiotClientServices.exe"...
I did a fresh install without a problem. Since the client updates immediately after the install, and that worked, I assume that other updates should work, too. Didn't have another update since then, though.
I now got an update and I got the same error.
Workaround: instead of starting LeagueClient.exe, start the installer and hit "Repair". This will install the update and start the launcher.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #110 from Matías Zúñiga matias.nicolas.zc@gmail.com --- (In reply to harry from comment #109)
Keep in mind that, while i can start the client and play a game, I can not update the riot client: "Update failed: Failed getting path to current executable: File path could not be found in a mapped drive: ??\C:\Riot Games\Riot Client\RiotClientServices.exe"...
I did a fresh install without a problem. Since the client updates immediately after the install, and that worked, I assume that other updates should work, too. Didn't have another update since then, though.
I now got an update and I got the same error.
Workaround: instead of starting LeagueClient.exe, start the installer and hit "Repair". This will install the update and start the launcher.
That should be Bug 51687. I'll send the patch there to the list one of these days now that the issue is more common.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #111 from alandms123@gmail.com --- Could we get a new version of glibc patching stuff? maybe for wine (>= 6.16) or (>= 7.0)?
I used to play using the vsyscall patch under wine 6.16 then I switched to wine 5.18 with glibc patch, but there's some minor issues with the client sometimes being complete black when alt-tabbing, also there's a chance of the game not respond to any event from mouse or keyboard (having to alt tab to make it work again).
https://bugs.winehq.org/show_bug.cgi?id=47198
neyl@tuta.io changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |neyl@tuta.io
--- Comment #112 from neyl@tuta.io --- With Wine 7.1 released we now have a lot of PE modules and WoW64 thunks. What is missing to get this bug properly fixed?
https://bugs.winehq.org/show_bug.cgi?id=47198
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|League of Legends 9.10 |League of Legends 9.10+ |Crash after champ select |crashes after champion | |select (anticheat, access | |of 64-bit TEB from WoW64 | |via %gs register) Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #113 from Zebediah Figura z.figura12@gmail.com --- (In reply to neyl from comment #112)
With Wine 7.1 released we now have a lot of PE modules and WoW64 thunks. What is missing to get this bug properly fixed?
Without changing the %cs segment, we still need:
* the ability to change %gs in the wine syscall thunk, which we can only safely do once all modules have been converted to PE. I'm going to go ahead and repurpose/narrow this bug report for this specific issue;
* the ability to execute 64-bit syscalls in a 32-bit process, which we can only safely do once all modules have WoW64 thunks written and the last parts of WoW64 support are in place. I've split this off into bug 52483;
* the ability to catch direct x86_64 SYSCALL instructions (bug 48291).
https://bugs.winehq.org/show_bug.cgi?id=47198
nyikoszoltan0@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|nyikoszoltan0@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #114 from David Torok dt@zeroitlab.com --- (In reply to Zebediah Figura from comment #113)
(In reply to neyl from comment #112)
With Wine 7.1 released we now have a lot of PE modules and WoW64 thunks. What is missing to get this bug properly fixed?
Without changing the %cs segment, we still need:
- the ability to change %gs in the wine syscall thunk, which we can only
safely do once all modules have been converted to PE. I'm going to go ahead and repurpose/narrow this bug report for this specific issue;
- the ability to execute 64-bit syscalls in a 32-bit process, which we can
only safely do once all modules have WoW64 thunks written and the last parts of WoW64 support are in place. I've split this off into bug 52483;
- the ability to catch direct x86_64 SYSCALL instructions (bug 48291).
Well, this was a while back but as I remember I don't believe syscalls were executed after the far jump that changes %cs. Between the 2 far jump %cs changes only the 64 bit TEB->PEB access happened. So as far as I understand, there is no need to be able to "directly execute" 64 bit syscalls from a 32 bit process. The normal "syscall path" for this application follows wine's own syscall thunks. (Therefore also eliminating the need to solve bug 48291)
The only one left I think is changing %gs.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #115 from Zebediah Figura z.figura12@gmail.com --- (In reply to David Torok from comment #114)
Well, this was a while back but as I remember I don't believe syscalls were executed after the far jump that changes %cs. Between the 2 far jump %cs changes only the 64 bit TEB->PEB access happened. So as far as I understand, there is no need to be able to "directly execute" 64 bit syscalls from a 32 bit process. The normal "syscall path" for this application follows wine's own syscall thunks. (Therefore also eliminating the need to solve bug 48291)
From the analysis shared with me by Andrew Wesie a couple years ago I believe
there were direct SYSCALL instructions. Note also the contents of attachment 64481. Perhaps that's changed since then.
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #116 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #115)
From the analysis shared with me by Andrew Wesie a couple years ago I believe there were direct SYSCALL instructions. Note also the contents of attachment 64481 [details]. Perhaps that's changed since then.
Okay, comment 90 explains the issue (buried under all of those user reports), I guess the SYSCALL instructions were in a fallback path. The normal path doesn't jump to 64-bit code at all, but uses the 32-bit ntdll. So we don't need bug 48291 or bug 52483.
https://bugs.winehq.org/show_bug.cgi?id=47198
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=47198
romulasry@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |romulasry@protonmail.com
https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #117 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 the patches here are no longer needed, so I think this bug should be closed.
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) which has a known workaround.
https://bugs.winehq.org/show_bug.cgi?id=47198
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|NEW |RESOLVED
--- Comment #118 from Zeb Figura z.figura12@gmail.com --- (In reply to Matías Zúñiga from comment #117)
Hi!. Since the 13.7 version, League of Legends uses a 64-bit game client, and the patches here are no longer needed, so I think this bug should be closed.
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) which has a known workaround.
Thanks, closing.
https://bugs.winehq.org/show_bug.cgi?id=47198
Jorge Pinilla Lopez tarmabal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tarmabal@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47198
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xdestac@gmail.com
--- Comment #119 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 47336 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47198
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #120 from Gijs Vermeulen gijsvrm@gmail.com --- Closing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla