http://bugs.winehq.org/show_bug.cgi?id=21232
Summary: Iron (Chrome) 4 can't load any webpage Product: Wine Version: 1.1.35 Platform: x86 URL: http://www.srware.net/downloads/srware_iron_beta.exe OS/Version: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
Trying Iron (basically iceweasel for Chrome) under wine, it fails to load any webpage. There is no terminal output when trying this. I've tried winetricks ie6 to get native wininet/winhttp, but that didn't help...
http://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #1 from Austin English austinenglish@gmail.com 2010-01-02 14:02:35 --- Forgot to add, doesn't seem to be an iron bug, Chrome's AppDB report shows the same: http://appdb.winehq.org/objectManager.php?sClass=version&iId=17588&i...
http://bugs.winehq.org/show_bug.cgi?id=21232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Iron (Chrome) 4 can't load |Chrome can't load any |any webpage |webpage unless --no-sandbox | |is used
--- Comment #2 from Austin English austinenglish@gmail.com 2011-05-21 17:48:17 CDT --- Found the workaround (mentioned in other bugs, but never saw a bug for it). Use --no-sandbox, which gets webpages to load fine.
Still in wine-1.3.20-230-g456e48e
http://bugs.winehq.org/show_bug.cgi?id=21232
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21232
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |28467
http://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #3 from fracting fracting@gmail.com 2012-01-08 14:19:25 CST --- Retest with wine-1.3.36-172-gb00e703 and ChromeStandaloneSetup-3700838267c7d2f01b3a4cf6802052967166bffa-2012-01-09.exe
Now Chrome tabs die at start up if --no-sandbox is not used.
"Aw, Snap! Something went wrong while displaying this webpage. ..."
http://bugs.winehq.org/show_bug.cgi?id=21232
zhtengw atenzd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |atenzd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30889
http://bugs.winehq.org/show_bug.cgi?id=21232
Felix Yan felixonmars@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felixonmars@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #4 from Felix Yan felixonmars@gmail.com 2012-06-18 06:09:31 CDT --- Still in wine 1.5.6.
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grendal74.geo@yahoo.com
--- Comment #5 from Anastasius Focht focht@gmx.net --- *** Bug 37105 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://downloads.sourceforg |http://www.srware.net/downl |e.net/portableapps/GoogleCh |oads/srware_iron_beta.exe |romePortable_37.0.2062.102_ | |online.paf.exe CC| |focht@gmx.net Summary|Chrome can't load any |Chrome crashes on startup |webpage unless --no-sandbox |unless '--no-sandbox' is |is used |used
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
since comment #3 re-christened the bug (don't do that), refining summary to collected dupes here.
Still present, it's a WONTFIX (will post analysis later).
Regards
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Status|NEW |RESOLVED Component|-unknown |ntdll Resolution|--- |WONTFIX Summary|Chrome crashes on startup |Chromium-based browser |unless '--no-sandbox' is |engines (Chrome, Opera) |used |crash on startup unless | |'--no-sandbox' is used | |(native API | |sandboxing/hooking scheme | |incompatible with Wine)
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
Chrome uses usermode syscall (native API) hooking to implement sandboxing. The hooking code makes assumptions about the NT syscall API entries which Wine can't implement for obvious reasons.
--- snip --- info process pid threads executable (all id:s are in hex) 00000022 1 'GoogleChromePortable.exe' 00000024 70 _ 'chrome.exe' --- snip ---
--- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+process,+module,+virtual,+server wine ./GoogleChromePortable.exe >>log.txt 2>&1 ... 0050: get_suspend_context( ) 0050: get_suspend_context() = 0 { context={cpu=x86,eip=f7772430,esp=0033ff14,ebp=0033ffe8,eflags=00000296,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=00000000,ebx=00000001,ecx=7bced260,edx=00000000,esi=00000008,edi=7bcd1000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0000,fp.tag=ffffffff,fp.err_off=00000000,fp.err_sel=00000023,fp.data_off=00000000,fp.data_sel=ffff002b,fp.cr0npx=00000000,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=0,extended={...}} } 0050:trace:module:process_attach (L"chrome.exe",0x1) - START 0050:trace:module:process_attach (L"chrome_elf.dll",0x1) - START 0050:trace:module:process_attach (L"KERNEL32.dll",0x1) - START 0050:trace:module:process_attach (L"ntdll.dll",0x1) - START 0050:trace:module:MODULE_InitDLL (0x7bc10000 L"ntdll.dll",PROCESS_ATTACH,0x1) - CALL 0050:trace:module:MODULE_InitDLL (0x7bc10000,PROCESS_ATTACH,0x1) - RETURN 1 0050:trace:module:process_attach (L"ntdll.dll",0x1) - END 0050:trace:module:MODULE_InitDLL (0x7b810000 L"KERNEL32.dll",PROCESS_ATTACH,0x1) - CALL 0050:trace:seh:raise_exception code=c0000005 flags=0 addr=0xfc365f ip=00fc365f tid=0050 0050:trace:seh:raise_exception info[0]=00000001 0050:trace:seh:raise_exception info[1]=00000000 0050:trace:seh:raise_exception eax=00000000 ebx=7bcd1000 ecx=0033f954 edx=0046a15c esi=0033fa30 edi=00000000 0050:trace:seh:raise_exception ebp=0033f948 esp=0033f940 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 0050:trace:seh:call_stack_handlers calling handler at 0x7bc9de50 code=c0000005 flags=0 0050:trace:seh:__regs_RtlUnwind code=c0000005 flags=2 0050:trace:seh:__regs_RtlUnwind calling handler at 0x7bc81835 code=c0000005 flags=2 0050:trace:seh:__regs_RtlUnwind handler at 0x7bc81835 returned 1 0050:trace:module:MODULE_InitDLL (0x7b810000,PROCESS_ATTACH,0x1) - RETURN 0 0050:trace:module:MODULE_InitDLL (0x7b810000 L"KERNEL32.dll",PROCESS_DETACH,0x1) - CALL 0050:trace:module:MODULE_InitDLL (0x7b810000,PROCESS_DETACH,0x1) - RETURN 1 0050:warn:module:process_attach Initialization of L"KERNEL32.dll" failed 0050:trace:module:process_attach (L"KERNEL32.dll",0x1) - END 0050:trace:module:process_attach (L"chrome_elf.dll",0x1) - END 0050:trace:module:process_attach (L"chrome.exe",0x1) - END 0050:err:module:attach_process_dlls "KERNEL32.dll" failed to initialize, aborting 0050:err:module:LdrInitializeThunk Main exe initialization for L"Z:\home\focht\Downloads\GoogleChromePortable\App\Chrome-bin\chrome.exe" failed, status c0000005 --- snip ---
Exception address is 0xfc365f in client address space (render sandbox).
Parent process injecting code for the hooker thunk and API entry:
--- snip --- ... 0030: write_process_memory( handle=0364, addr=00fc3650, data={8d,4c,24,04,83,e4,f0,ff,71,fc,55,89,e5,53,51,83,6c,00,00,00,00,00,00,00,83,ec,08,52,8b,54,24,0c,89,54,24,08,c7,44,24,0c,50,36,fc,00,c7,44,24,04,1b,0e,44,00,5a,c3} ) 0030: write_process_memory() = 0 ... 0030: read_process_memory( handle=0364, addr=7bc5be28 ) 0030: read_process_memory() = 0 { data={8d,4c,24,04,83,e4,f0,ff,71,fc,55,89,e5,53,51,83} } ... 0030: write_process_memory( handle=0364, addr=7bc5be28, data={b8,4c,24,04,83,ba,68,36,fc,00,ff,e2} ) 0050: *signal* signal=19 0030: write_process_memory() = 0 --- snip ---
Original 'NtOpenThreadToken' API entry:
--- snip --- $ ==> 7BC5BE28 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4] $+4 7BC5BE2C 83E4 F0 AND ESP,FFFFFFF0 $+7 7BC5BE2F FF71 FC PUSH DWORD PTR DS:[ECX-4] $+A 7BC5BE32 55 PUSH EBP $+B 7BC5BE33 89E5 MOV EBP,ESP $+D 7BC5BE35 53 PUSH EBX $+E 7BC5BE36 51 PUSH ECX $+F 7BC5BE37 83EC 20 SUB ESP,20 $+12 7BC5BE3A E8 D12CFCFF CALL ntdll.__x86.get_pc_thunk.bx $+17 7BC5BE3F 81C3 C1510700 ADD EBX,751C1 $+1D 7BC5BE45 89C8 MOV EAX,ECX $+1F 7BC5BE47 8B50 08 MOV EDX,DWORD PTR DS:[EAX+8] $+22 7BC5BE4A 8855 F4 MOV BYTE PTR SS:[EBP-C],DL $+25 7BC5BE4D 0FB655 F4 MOVZX EDX,BYTE PTR SS:[EBP-C] $+29 7BC5BE51 8B48 0C MOV ECX,DWORD PTR DS:[EAX+C] $+2C 7BC5BE54 894C24 10 MOV DWORD PTR SS:[ESP+10],ECX $+30 7BC5BE58 C74424 0C 00000000 MOV DWORD PTR SS:[ESP+C],0 $+38 7BC5BE60 895424 08 MOV DWORD PTR SS:[ESP+8],EDX $+3C 7BC5BE64 8B50 04 MOV EDX,DWORD PTR DS:[EAX+4] $+3F 7BC5BE67 895424 04 MOV DWORD PTR SS:[ESP+4],EDX $+43 7BC5BE6B 8B00 MOV EAX,DWORD PTR DS:[EAX] $+45 7BC5BE6D 890424 MOV DWORD PTR SS:[ESP],EAX $+48 7BC5BE70 E8 0F000000 CALL ntdll.NtOpenThreadTokenEx $+4D 7BC5BE75 83EC 14 SUB ESP,14 $+50 7BC5BE78 8D65 F8 LEA ESP,DWORD PTR SS:[EBP-8] $+53 7BC5BE7B 59 POP ECX $+54 7BC5BE7C 5B POP EBX $+55 7BC5BE7D 5D POP EBP $+56 7BC5BE7E 8D61 FC LEA ESP,DWORD PTR DS:[ECX-4] $+59 7BC5BE81 C2 1000 RETN 10 --- snip ---
(1) API entry after hook patch:
--- snip --- $ 7BC5BE28 B8 4C240483 MOV EAX,8304244C $+5 7BC5BE2D BA 682E8500 MOV EDX,852E68 $+A 7BC5BE32 FFE2 JMP EDX ... --- snip ---
(2) Internal thunk (trampoline) to final hooker code:
--- snip --- $+18 00196080 83EC 08 SUB ESP,8 $+1B 00196083 52 PUSH EDX $+1C 00196084 8B5424 0C MOV EDX,DWORD PTR SS:[ESP+C] $+20 00196088 895424 08 MOV DWORD PTR SS:[ESP+8],EDX $+24 0019608C C74424 0C 502E8500 MOV DWORD PTR SS:[ESP+C],852E50 $+2C 00196094 C74424 04 1B0E4400 MOV DWORD PTR SS:[ESP+4],440E1B $+34 0019609C 5A POP EDX $+35 0019609D C3 RETN --- snip ---
(3) Hooker code:
--- snip --- 0x00440e1b: pushl %ebp 0x00440e1c: movl %esp,%ebp 0x00440e1e: call 0x0042e5f4 0x00440e23: movl %eax,%ecx 0x00440e25: movl 0x0(%eax),%edx 0x00440e27: call *0x8(%edx) 0x00440e2a: movl %eax,%ecx 0x00440e2c: call 0x00430c42 0x00440e31: pushl 0x18(%ebp) ... --- snip ---
(4) Copy of original API entry code in client address space (sandbox):
--- snip --- $ ==> 00196068 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4] $+4 0019606C 83E4 F0 AND ESP,FFFFFFF0 $+7 0019606F FF71 FC PUSH DWORD PTR DS:[ECX-4] $+A 00196072 55 PUSH EBP $+B 00196073 89E5 MOV EBP,ESP $+D 00196075 53 PUSH EBX $+E 00196076 51 PUSH ECX $+F 00196077 8373 00 65 XOR DWORD PTR DS:[EBX],65 ; *boom* $+13 0019607B 0072 00 ADD BYTE PTR DS:[EDX],DH $+16 0019607E 73 00 JNB SHORT 00196080 --- snip ---
The parent process hook engine copies up to 16 bytes from the native API entry to a client process "save" area which is later used as continuation after the hook code is done.
NT-style usermode syscall entries have fixed architecture-specific layout which doesn't exceed 16 bytes. The crash is caused by the fact that Wine's native API implementation is "normal" code and the hooker copying just stops short in the middle of opcode sequence.
Resolving 'WONTFIX'.
Since a native client exists for Linux there is no real loss here.
As a matter of fact Opera uses exactly the same hooking scheme for their sandbox, see bug 33698 (Opera switched to Chrome code base).
Regards
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ryanfarmer@gmx.com
--- Comment #8 from Anastasius Focht focht@gmx.net --- *** Bug 33698 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #9 from grendal74 grendal74.geo@yahoo.com --- Adding http://en.wikipedia.org/wiki/Comodo_Dragon to the affected browsers (same bug)
http://www.comodo.com/home/browsers-toolbars/browser.php
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Chromium-based browser |Chromium-based browser |engines (Chrome, Opera) |engines (Chrome, Opera, |crash on startup unless |Comodo Dragon) crash on |'--no-sandbox' is used |startup unless |(native API |'--no-sandbox' is used |sandboxing/hooking scheme |(native API |incompatible with Wine) |sandboxing/hooking scheme | |incompatible with Wine)
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello grendal74,
thanks, I've adjusted the summary to include that browser.
Regards
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |giorgosk67@gmail.com
--- Comment #11 from Anastasius Focht focht@gmx.net --- *** Bug 35697 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #12 from grendal74 grendal74.geo@yahoo.com --- Hello Anastasius,
you can add http://www.srware.net/en/software_srware_iron_download.php as well, just tried Version: 36.0.1950.0
Unhandled exception: 0xc06d007f in 32-bit code (0x7b83af9e). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b83af9e ESP:0033e054 EBP:0033e0c8 EFLAGS:00000287( - -- I S - -P-C) EAX:7b826ca9 EBX:7b8b9000 ECX:0033e0f8 EDX:0033e074 ESI:c06d007f EDI:b71e0000
etc.
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Chromium-based browser |Chromium-based browser |engines (Chrome, Opera, |engines (Chrome, Opera, |Comodo Dragon) crash on |Comodo Dragon, SRWare Iron) |startup unless |crash on startup unless |'--no-sandbox' is used |'--no-sandbox' is used |(native API |(native API |sandboxing/hooking scheme |sandboxing/hooking scheme |incompatible with Wine) |incompatible with Wine)
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |unxed@mail.ru
--- Comment #13 from Anastasius Focht focht@gmx.net --- *** Bug 32838 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |litimetal@gmail.com
--- Comment #15 from Anastasius Focht focht@gmx.net --- *** Bug 34249 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #16 from Sebastian Lackner sebastian@fds-team.de --- Steam is now also affected by this, see https://bugs.winehq.org/show_bug.cgi?id=39403
We should maybe consider to reopen this issue...
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX |---
--- Comment #17 from Anastasius Focht focht@gmx.net --- Hello Sebastian
--- quote --- Steam is now also affected by this, see https://bugs.winehq.org/show_bug.cgi?id=39403
We should maybe consider to reopen this issue... --- quote ---
Sure ...
Regards
https://bugs.winehq.org/show_bug.cgi?id=21232
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Greg R. Perry greg@gregrperry.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |greg@gregrperry.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
https://bugs.winehq.org/show_bug.cgi?id=21232
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Aaron Franke arnfranke@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arnfranke@yahoo.com
--- Comment #18 from Aaron Franke arnfranke@yahoo.com --- Probably related: https://bugs.winehq.org/show_bug.cgi?id=43415
https://bugs.winehq.org/show_bug.cgi?id=21232
Aaron Franke arnfranke@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43415
https://bugs.winehq.org/show_bug.cgi?id=21232
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=21232
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=39403 CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=21232
Johan Gardhage johan.gardhage@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Aaron Franke arnfranke@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |44117
https://bugs.winehq.org/show_bug.cgi?id=21232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|44117 |
--- Comment #19 from Austin English austinenglish@gmail.com --- *** Bug 44117 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Aaron Franke arnfranke@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |44117
https://bugs.winehq.org/show_bug.cgi?id=21232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|44117 |
https://bugs.winehq.org/show_bug.cgi?id=21232
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
--- Comment #20 from Robert Walker bob.mt.wya@gmail.com --- Can this bug be linked to Steam directly? Or is it just related...?? This bug appears to refer to standalone chrome rather than CEF. I've had a user submit a link request. Thank you muchly.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #21 from Aaron Franke arnfranke@yahoo.com --- Robert Walker, AFAIK the bug referring to Chrome specifically is https://bugs.winehq.org/show_bug.cgi?id=43415
39403 refers to Steam directly but this bug was reopened because of Steam. While I cannot directly edit the blocks/depends-on of either bug, I am pretty sure that 39403 depends on this bug being fixed.
Quoting another comment on this bug:
"--- quote --- Steam is now also affected by this, see https://bugs.winehq.org/show_bug.cgi?id=39403
We should maybe consider to reopen this issue... --- quote ---
Sure ..."
https://bugs.winehq.org/show_bug.cgi?id=21232
Evgenii Burmentev [:virus_found] vir.found@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vir.found@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Linards linards.liepins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linards.liepins@gmail.com
--- Comment #22 from Linards linards.liepins@gmail.com --- Confirming to happen on wine-3.2 (Steam installed via winetricks).
Details:
[linards@kompiic Lejupielādes]$ sh winetricks list-installed ------------------------------------------------------ You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug. ------------------------------------------------------ Using winetricks 20180217-next - sha256sum: 6dd23a6c59febc56a2c5a31aabc0c1b92545ec176c64b494aa088c5d993bf588 with wine-3.2 and WINEARCH=win64 binkw32 d3dx9_42 dotnet40 dotnet452 dotnet_verifier gmdls l3codecx lucida mfc40 mfc42 physx steam tahoma vcrun2008 vcrun2012 vcrun2013 vcrun2015
https://bugs.winehq.org/show_bug.cgi?id=21232
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=21232
romulasry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |romulasry@gmail.com
--- Comment #23 from romulasry@gmail.com --- Confirmed with Wine 3.5.
https://bugs.winehq.org/show_bug.cgi?id=21232
Max Qian public@maxqia.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |public@maxqia.com
--- Comment #24 from Max Qian public@maxqia.com --- I'd like to note that there seems like a solution to the hooking problem now. In wine-staging there's a patchset that implements the syscall thunks needed. https://github.com/wine-staging/wine-staging/tree/master/patches/winebuild-F...
It looks like it's exactly what chrome expects to be there. (at least for 32 bit, 64 bit doesn't quite right) https://github.com/wine-staging/wine-staging/blob/11233f0810251da8ca98077ace...
https://github.com/chromium/chromium/blob/f18e79d901f56154f80eea1e2218544285...
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/HEAD | |/patches/winebuild-Fake_Dll | |s Status|REOPENED |STAGED
--- Comment #25 from Anastasius Focht focht@gmx.net --- Hello Max,
--- quote --- I'd like to note that there seems like a solution to the hooking problem now. In wine-staging there's a patchset that implements the syscall thunks needed. ... It looks like it's exactly what chrome expects to be there. (at least for 32 bit, 64 bit doesn't quite right) --- quote ---
did you verify with 32-bit Chromium build that it's sufficient?
Anyway, setting staged at least for the 32-bit part.
Bug 42741 references the same Wine-Staging patchset https://github.com/wine-staging/wine-staging/tree/HEAD/patches/winebuild-Fak... but is messed up from traceability point of view (multiple issues covering different areas = bad).
Regards
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #26 from Max Qian public@maxqia.com --- (In reply to Anastasius Focht from comment #25)
Hello Max,
--- quote --- I'd like to note that there seems like a solution to the hooking problem now. In wine-staging there's a patchset that implements the syscall thunks needed. ... It looks like it's exactly what chrome expects to be there. (at least for 32 bit, 64 bit doesn't quite right) --- quote ---
did you verify with 32-bit Chromium build that it's sufficient?
Anyway, setting staged at least for the 32-bit part.
Bug 42741 references the same Wine-Staging patchset https://github.com/wine-staging/wine-staging/tree/HEAD/patches/winebuild- Fake_Dlls but is messed up from traceability point of view (multiple issues covering different areas = bad).
Regards
No, I meant to say that it's not crashing on the hook now, it's crashing on something else, so there has been progress.
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spoon0042@hotmail.com
--- Comment #27 from Anastasius Focht focht@gmx.net --- *** Bug 39403 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45349
https://bugs.winehq.org/show_bug.cgi?id=21232
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=21232
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #28 from Jacek Caban jacek@codeweavers.com --- For the reference, here is source code of problematic parts of sandbox code:
https://chromium.googlesource.com/chromium/src/sandbox/+/master/win/src/serv... https://chromium.googlesource.com/chromium/src/sandbox/+/master/win/src/serv...
And a discussion on wine-devel:
https://www.winehq.org/pipermail/wine-devel/2016-January/111293.html
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #29 from Fabian Maurer dark.shadow4@web.de --- I'm not sure how to properly test this issue. Do we have tests for this issue? If no, would writing tests for that be useful?
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #30 from Zebediah Figura z.figura12@gmail.com --- (In reply to Fabian Maurer from comment #29)
I'm not sure how to properly test this issue. Do we have tests for this issue? If no, would writing tests for that be useful?
I'm not sure writing tests is useful until we can be sure that we have a way to solve this problem, which we may never have.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #31 from Max Qian public@maxqia.com --- Created attachment 61762 --> https://bugs.winehq.org/attachment.cgi?id=61762 sbox_unittests.exe Windows Output
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #32 from Max Qian public@maxqia.com --- Created attachment 61763 --> https://bugs.winehq.org/attachment.cgi?id=61763 sbox_unittests.exe Wine 3.11 Output
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #33 from Max Qian public@maxqia.com --- Created attachment 61764 --> https://bugs.winehq.org/attachment.cgi?id=61764 sbox_unittests.exe Wine Staging 3.12 Output
So I built sbox_unittests.exe and recorded the outputs for Windows 10, Wine, and Wine Staging (with the dbghelp messages grep'd out). Running the test on unpatched Wine resulted in it page faulting in the interception tests which Wine Staging didn't. The ServiceResolverTest.PatchesServices also failed on both versions of Wine.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #34 from Max Qian public@maxqia.com --- To clarify a bit more, I built sbox_unittests.exe from the chromium source target "sandbox/win:sbox_unittests" on Windows 10.
https://bugs.winehq.org/show_bug.cgi?id=21232
Max Qian public@maxqia.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #61764|0 |1 is obsolete| |
--- Comment #35 from Max Qian public@maxqia.com --- Created attachment 61765 --> https://bugs.winehq.org/attachment.cgi?id=61765 sbox_unittests.exe Wine Staging 3.12 (64 bit prefix)
I forgot that the staged patch set is based on a WoW64 system. Testing on the 64 bit prefix shows that all the tests for hooking run successfully.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #36 from Zebediah Figura z.figura12@gmail.com --- 32-bit and WOW64 is doable as far as Chromium is concerned, but is there any way to make this actually work on 64-bit?
Furthermore, does WOW64 still work if you change the reported Wine version?
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #37 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61770 --> https://bugs.winehq.org/attachment.cgi?id=61770 Proof of Concept
(In reply to Zebediah Figura from comment #36)
32-bit and WOW64 is doable as far as Chromium is concerned, but is there any way to make this actually work on 64-bit?
I didn't see a method mentioned here, but I made a Proof of Concept. It's the only method I found that's viable at least - we can't intercept syscalls in userland.
According to https://chromium.googlesource.com/chromium/src/sandbox/+/master/win/src/serv... new win10 has a fallback to "int 2e" for interrupts. Don't ask me why, but my tests confirm this true, and this opens an opportunity for us to provide patchability.
Running "int 2e" results under Linux x64 to a segfault (not sure how certain this is though) and we can catch and handle this. It might not be a pretty solution, but it should do the job.
Of course, running this many SIGSEVs could impact the performance (need to test that), but it could be made conditional. AFAIK most people shouldn't depend on native APIs, so maybe we could only enable that hooking feature when needed. I thought of the lines of making the stub a simple jump to the actual function, and when GetProcAddress for an hookable Nt-function is called, the jumps are converted into "int 2e; ret" resulting in the slower, patchable code..
Attached a small demo on how I think it could work. I plan to make patches for actual wine to try it out this weekend. What do you think about that?
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #38 from Max Qian public@maxqia.com --- Latest Chrome doesn't work on 32 bit/WinXP anymore. The staged patch also works for 64 bit (last patch if you want to look), but it acts like Windows 7, and if you have your OS set differently, Chrome will hook into it wrong. So far, I've gotten Chrome not to crash. The GPU/Compositor part doesn't seem to work though. I'll work on 64 bit once I get 32 bit running, it shouldn't be hard to port the patches.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #39 from Fabian Maurer dark.shadow4@web.de ---
The staged patch also works for 64 bit (last patch if you want to look), but it acts like Windows 7, and if you have your OS set differently, Chrome will hook into it wrong.
How did you get Chrome x64 to work? Correct me if I'm wrong, but I though the issue is that the syscall is part of the thunk and chrome checks for that, but the staging patches don't solve that issue. The staging patches don't implement the 64bit thunks the way chrome expects them, at least for me it doesn't work.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #40 from Max Qian public@maxqia.com --- Oh wait, yeah you're right. I think I got some code mixed up.
https://bugs.winehq.org/show_bug.cgi?id=21232
zhtengw atenzd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|atenzd@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #41 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61800 --> https://bugs.winehq.org/attachment.cgi?id=61800 Provide hookable 64bit native api thunks
I created an experimental patch to run x64 chrome without "--no-sandbox".
Please note that this is mostly a PoC still, it's not very tested yet. And possibly broken on non-Linux platforms. I only tested pure 64bit wine on Linux with google chrome.
The concept is the one I proposed in Comment 37, and subjective speed seems acceptable. The patch is built on top of wine-staging, extending the work that already was done.
Note that we need to register the signal handler early and then overwrite it, since the ntapi is used pretty early on (might be able to get rid of that). We also need to set SystemCallPad twice, because it needs to be set pretty early on too, but would get overwritten later.
Can someone test if that fixes the issue for you too? If you find it causes issues, please tell me.
https://bugs.winehq.org/show_bug.cgi?id=21232
William Feely BFeely@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |BFeely@aol.com
--- Comment #42 from William Feely BFeely@aol.com --- This bug also now affects the new chat in Steam Beta, which is Chromium based. As such the chat is disabled and the client is stuck in Invisible mode. Since Valve plans on migrating more of the Steam Client to a CEF-based UI, it might be important to prioritize fixing this issue.
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45573
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brandon_bunning1@mymail.eku | |.edu
--- Comment #43 from Zebediah Figura z.figura12@gmail.com --- *** Bug 45327 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Chromium-based browser |Multiple games and |engines (Chrome, Opera, |applications |Comodo Dragon, SRWare Iron) |(Chromium-based browser |crash on startup unless |engines, Blizzard games, |'--no-sandbox' is used |League of Legends) crash |(native API |due to hooking/anticheat |sandboxing/hooking scheme |validation (needs syscall |incompatible with Wine) |thunks in ntdll.dll)
--- Comment #44 from Zebediah Figura z.figura12@gmail.com --- Changing title to more accurately reflect scope.
https://bugs.winehq.org/show_bug.cgi?id=21232
invictustiberius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |invictustiberius@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #45 from Fabian Maurer dark.shadow4@web.de --- As of today, I couldn't get chrome32 to work even with the staging patches. Tested with version from https://portableapps.com/de/apps/internet/google_chrome_portable Tried with different windows versions in winecfg, but doesn't work. Can someone confirm? Maybe there's something missing, it works with "--no-sandbox"
Sidenote: My patch for x64 chrome still works for chrome from https://portableapps.com/apps/internet/google-chrome-portable-64, but not for chromium from https://storage.googleapis.com/chromium-browser-snapshots/win_rel/581906/chr...
https://bugs.winehq.org/show_bug.cgi?id=21232
jaapbuurman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaapbuurman@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45650
--- Comment #46 from Fabian Maurer dark.shadow4@web.de --- There's a lot of open issues with the chromium sandbox, but also two two issues with the api thunks.
See bug 45650 for the 32bit syscall thunks issue and bug 45642 for the 64bit syscall thunks issues - I split them of to not pollute this already big bug report.
Also see the other issues I created for chromium as to why this alone doesn't make it work - it's often hard to see why the sandbox doesn't want to work.
https://bugs.winehq.org/show_bug.cgi?id=21232
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45642
https://bugs.winehq.org/show_bug.cgi?id=21232
mail+wine@m-reimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail+wine@m-reimer.de
--- Comment #47 from mail+wine@m-reimer.de --- This bug is marked "STAGED" now, but problem is, that the "main bug" about the LoL problems, which is:
https://bugs.winehq.org/show_bug.cgi?id=45327
was marked as duplicate of this one here.
The patcheset in Bug 45327 is still valid and required to run LoL, right?
If so, please reopen Bug 45327 before closing this one.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #48 from Zebediah Figura z.figura12@gmail.com --- (In reply to mail+wine from comment #47)
This bug is marked "STAGED" now, but problem is, that the "main bug" about the LoL problems, which is:
https://bugs.winehq.org/show_bug.cgi?id=45327
was marked as duplicate of this one here.
The patcheset in Bug 45327 is still valid and required to run LoL, right?
If so, please reopen Bug 45327 before closing this one.
The patch set in bug 45327 has also been staged. Each patch addresses a separate issue, and so they were filed as separate bugs (45566 through 45573).
https://bugs.winehq.org/show_bug.cgi?id=21232
alasky@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasky@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Jan Simek jsimek.cz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsimek.cz@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Guo Yunhe (郭云鹤) guoyunhebrave@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guoyunhebrave@gmail.com
--- Comment #49 from Guo Yunhe (郭云鹤) guoyunhebrave@gmail.com --- I installed League of Legends 9.4 and Wine Staging 4.2 (openSUSE Tumbleweed), the client works but the game still crash every time.
https://bugs.winehq.org/show_bug.cgi?id=21232
George Gibbs vash63@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vash63@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #50 from Aaron Franke arnfranke@yahoo.com --- https://www.youtube.com/watch?v=F4Zoiyfk9v4
An update to the Steam client, which will likely be coming soon, will use the Chromium engine for the library. This means that every single function of Steam will use web UIs and Steam will become useless in Wine. When this happens, every single Steam game will become unlaunchable in Wine via normal means.
Because of this, I think this needs to be elevated to Wine's #1 priority issue.
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #51 from William Feely BFeely@aol.com --- (In reply to Aaron Franke from comment #50)
https://www.youtube.com/watch?v=F4Zoiyfk9v4
An update to the Steam client, which will likely be coming soon, will use the Chromium engine for the library. This means that every single function of Steam will use web UIs and Steam will become useless in Wine. When this happens, every single Steam game will become unlaunchable in Wine via normal means.
Because of this, I think this needs to be elevated to Wine's #1 priority issue.
Considering that the alpha can be enabled by downloading a file from the Steam CDN and using a special command line, I suspect Steam may still have for at least a while a fallback mode.
https://bugs.winehq.org/show_bug.cgi?id=21232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |5tarasm@gmail.com
--- Comment #52 from Anastasius Focht focht@gmx.net --- *** Bug 43548 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-sta |https://github.com/wine-sta |ging/wine-staging/tree/HEAD |ging/wine-staging/tree/mast |/patches/winebuild-Fake_Dll |er/patches/winebuild-Fake_D |s |lls
https://bugs.winehq.org/show_bug.cgi?id=21232
ahonnecke+winehq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ahonnecke+winehq@gmail.com
--- Comment #53 from ahonnecke+winehq@gmail.com --- Present in wine 5.7
https://bugs.winehq.org/show_bug.cgi?id=21232
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=21232
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Darksaber203@protonmail.com
--- Comment #54 from Louis Lenders xerox.xerox2000x@gmail.com --- *** Bug 49632 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=21232
Luke Bratch luke@bratch.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke@bratch.co.uk
https://bugs.winehq.org/show_bug.cgi?id=21232
--- Comment #55 from Fabian Maurer dark.shadow4@web.de --- As of now, the winebuild-Fake_Dlls patchset is missing and it seems upstreamed. What is the current state of this?
All I can say, is that chromium/CEF still have sandbox issues, not 100% sure if it's the syscalls though...
https://bugs.winehq.org/show_bug.cgi?id=21232
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |917a206b01c82170a862e8497cb | |e26b6f1bfade0
--- Comment #56 from Zebediah Figura z.figura12@gmail.com --- (In reply to Fabian Maurer from comment #55)
As of now, the winebuild-Fake_Dlls patchset is missing and it seems upstreamed. What is the current state of this?
All I can say, is that chromium/CEF still have sandbox issues, not 100% sure if it's the syscalls though...
This should be marked fixed as of 917a206b01c82170a862e8497cbe26b6f1bfade0; compatible system call thunks are present in i386 and x86-64. Further problems should be relegated to new bug reports.
https://bugs.winehq.org/show_bug.cgi?id=21232
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #57 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.18.
https://bugs.winehq.org/show_bug.cgi?id=21232
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pentarctagon@tutamail.com
--- Comment #58 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 39587 has been marked as a duplicate of this bug. ***