[Bug 37585] New: 64-bit Google Chrome 38.x crashes (core dlls must be prelinked at fixed addresses)
https://bugs.winehq.org/show_bug.cgi?id=37585
Bug ID: 37585 Summary: 64-bit Google Chrome 38.x crashes (core dlls must be prelinked at fixed addresses) Product: Wine Version: 1.7.31 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: focht@gmx.net Distribution: ---
Hello folks,
as 64-bit Google Chrome has finally been released I thought to give it a try.
Only useful for improving Wine 64-bit compatibility, not really meant to be used seriously since native port exists.
--- snip --- $ pwd /home/focht/wineprefix64/drive_c/Program Files (x86)/Google/Chrome/Application
$ file chrome.exe chrome.exe: PE32+ executable (GUI) x86-64, for MS Windows
$ WINEDEBUG=+tid,+seh,+relay,+server,+virtual,+module wine64 ./chrome.exe
log.txt 2>&1
... 003f:Call advapi32.CreateProcessAsUserW(000002f8,05fad480 L"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",0011f680 L""C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --type=renderer --enable-deferred-image-decoding --lang=en-US --force-fieldtrials=Prerender/PrerenderEnabled/UMA-New-Install-Uniformity-Trial/Control/UMA-Session-Randomized-Uniformity-Trial-5-Percent/default/UMA-Uniformity-Trial-1-P"...,00000000,00000000,00000000,383330300100040c,00000000,00000000,05bbc4d0,05bbbe98) ret=14003e6bb ... 003f: new_process() = 0 { info=0308, pid=0051, phandle=030c, tid=0052, thandle=0310 } 003f: select( flags=2, cookie=05bbadb4, timeout=infinite, prev_apc=0000, result={}, data={WAIT,handles={0308}} ) 003f: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 } 003f: *wakeup* signaled=0 003f: get_new_process_info( info=0308 ) 003f: get_new_process_info() = 0 { success=1, exit_code=259 } 003f: close_handle( handle=0308 ) 003f: close_handle() = 0 003f: close_handle( handle=0304 ) 003f: close_handle() = 0 003f:Ret advapi32.CreateProcessAsUserW() retval=00000001 ret=14003e6bb ... 003f:Call KERNEL32.VirtualAllocEx(0000030c,00000000,0000006c,00001000,00000004) ret=1400443eb 003f:trace:virtual:NtAllocateVirtualMemory 0x30c (nil) 0000006c 1000 00000004 003f: queue_apc( handle=030c, call={APC_VIRTUAL_ALLOC,addr==00000000,size=0000006c,zero_bits=0,op_type=1000,prot=4} ) 003f: queue_apc() = 0 { handle=0304, self=0 } 003f: select( flags=2, cookie=05bbbc14, timeout=infinite, prev_apc=0000, result={}, data={WAIT_ALL,handles={0304}} ) 003f: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 } 003f: *wakeup* signaled=0 003f: get_apc_result( handle=0304 ) 003f: get_apc_result() = 0 { result={APC_VIRTUAL_ALLOC,status=0,addr=00240000,size=00001000} } 003f:Ret KERNEL32.VirtualAllocEx() retval=00240000 ret=1400443eb 003f:Call KERNEL32.WriteProcessMemory(0000030c,00240000,00113070,0000006c,05bbc350) ret=14004440f 003f: write_process_memory( handle=030c, addr=00240000, data={01,00,00,00,00,00,00,00,00,00,00,00,60,00,00,00,00,00,00,00,30,00,00,00,00,00,00,00,01,00,00,00,00,33,6b,00,65,00,72,00,6e,00,65,00,6c,00,33,00,32,00,2e,00,64,00,6c,00,6c,00,00,00,30,00,00,00,00,00,00,00,02,00,00,00,0e,00,00,00,78,e0,04,40,01,00,00,00,43,72,65,61,74,65,4e,61,6d,65,64,50,69,70,65,57,00,00,00,00,01,00,11,00} ) 003f: write_process_memory() = 0 003f:Ret KERNEL32.WriteProcessMemory() retval=00000001 ret=14004440f .... 003f:Call KERNEL32.VirtualAllocEx(0000030c,0025c000,00001000,00001000,100000040) ret=140044b18 003f:trace:virtual:NtAllocateVirtualMemory 0x30c 0x25c000 00001000 1000 00000040 003f: queue_apc( handle=030c, call={APC_VIRTUAL_ALLOC,addr==0025c000,size=00001000,zero_bits=0,op_type=1000,prot=40} ) 003f: queue_apc() = 0 { handle=0304, self=0 } 003f: select( flags=2, cookie=05bbbb94, timeout=infinite, prev_apc=0000, result={}, data={WAIT_ALL,handles={0304}} ) 003f: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 } 003f: *wakeup* signaled=0 003f: get_apc_result( handle=0304 ) 003f: get_apc_result() = 0 { result={APC_VIRTUAL_ALLOC,status=0,addr=0025c000,size=00001000} } 003f:Ret KERNEL32.VirtualAllocEx() retval=0025c000 ret=140044b18 003f:Call KERNEL32.GetModuleHandleW(14007d2b0 L"ntdll.dll") ret=1400447aa 003f:trace:module:LdrGetDllHandle L"ntdll.dll" -> 0x7fa7c6270000 (load path L"C:\Program Files (x86)\Google\Chrome\Application;.;C:\windows\system32;C:\windows\system;C:\windows;C:\windows\system32;C:\windows;C:\windows\system32\wbem") 003f:Ret KERNEL32.GetModuleHandleW() retval=7fa7c6270000 ret=1400447aa 003f:Call KERNEL32.GetModuleHandleExW(00000006,7fa7c6273fe0,05bbc0e0) ret=1400447f5 003f:Ret KERNEL32.GetModuleHandleExW() retval=00000001 ret=1400447f5 ... 003f:Call KERNEL32.ReadProcessMemory(0000030c,7fa7c627462c,05bbc010,00000020,05bbc040) ret=14004e728 003f: read_process_memory( handle=030c, addr=7fa7c627462c ) 003f: read_process_memory() = ACCESS_VIOLATION { data={} } 003f:Ret KERNEL32.ReadProcessMemory() retval=00000000 ret=14004e728 ... 003f:Call KERNEL32.GetLastError() ret=14003bb29 003f:Ret KERNEL32.GetLastError() retval=000003e6 ret=14003bb29 003f:Call KERNEL32.TerminateProcess(0000030c,00000000) ret=14003eafd 003f: terminate_process( handle=030c, exit_code=0 ) 003f: terminate_process() = 0 { self=0 } 003f:Ret KERNEL32.TerminateProcess() retval=00000001 ret=14003eafd 003f:Call KERNEL32.WaitForSingleObject(0000030c,00000032) ret=14003e406 003f: select( flags=2, cookie=05bbbdc4, timeout=+0.0500000, prev_apc=0000, result={}, data={WAIT,handles={030c}} ) 003f: select() = 0 { timeout=1d0037eb30ca43e (+0.0500000), call={APC_NONE}, apc_handle=0000 } 003f:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=14003e406 003f:Call KERNEL32.GetExitCodeProcess(0000030c,05bbc3d0) ret=14003e414 003f: get_process_info( handle=030c ) 003f: get_process_info() = 0 { pid=0051, ppid=0008, affinity=0000000f, peb=7fffff7ef000, start_time=1d0037eb2fe710c (-0.0431540), end_time=1d0037eb304b832 (-0.0020110), exit_code=0, priority=2, cpu=x86_64, debugger_present=0 } 003f:Ret KERNEL32.GetExitCodeProcess() retval=00000001 ret=14003e414 ... 003f:trace:seh:raise_exception code=80000003 flags=0 addr=0x14001d86d ip=14001d86d tid=003f 003f:trace:seh:raise_exception rax=0000000000000000 rbx=00000001400a3f88 rcx=0000000005bbeb1f rdx=0000000005bbeae0 003f:trace:seh:raise_exception rsi=0000000000110980 rdi=000000000000dead rbp=0000000005bbc500 rsp=0000000005bbc3d0 003f:trace:seh:raise_exception r8=0000003071e48cfd r9=000000000000001e r10=0000000000000000 r11=0000003071f811c0 003f:trace:seh:raise_exception r12=0000000000101160 r13=0000000000101140 r14=0000000000075680 r15=000000000000dead --- snip ---
Child process address space for 64-bit 'ntdll.dll':
--- snip --- 0054:trace:module:load_dll looking for L"ntdll.dll" in L"C:\Program Files (x86)\Google\Chrome\Application;.;C:\windows\system32;C:\windows\system;C:\windows;C:\windows\system32;C:\windows;C:\windows\system32\wbem" 0054:trace:module:load_dll Found L"C:\windows\system32\ntdll.dll" for L"ntdll.dll" at 0x7f3184050000, count=3 0054:trace:virtual:NtProtectVirtualMemory 0xffffffffffffffff 0x7f317d8f9bc0 000002d0 00000004 0054:trace:virtual:VIRTUAL_SetProt 0x7f317d8f9000-0x7f317d8f9fff c-rW- 0054:trace:virtual:VIRTUAL_DumpView View: 0x7f317d680000 - 0x7f317d8fbfff (system) 0054:trace:virtual:VIRTUAL_DumpView 0x7f317d680000 - 0x7f317d680fff c-r-- 0054:trace:virtual:VIRTUAL_DumpView 0x7f317d681000 - 0x7f317d8f4fff c-r-x 0054:trace:virtual:VIRTUAL_DumpView 0x7f317d8f5000 - 0x7f317d8f8fff c-rw- 0054:trace:virtual:VIRTUAL_DumpView 0x7f317d8f9000 - 0x7f317d8f9fff c-rW- 0054:trace:virtual:VIRTUAL_DumpView 0x7f317d8fa000 - 0x7f317d8fbfff c-rw- --- snip ---
App sandboxing scheme at work, setting up intermediate trampoline code in the child and then patch out the API entries.
Unfortunately the code relies on 64-bit Windows core dlls being mapped at the same (fixed) locations across processes hence it fails here, triggering abort in the parent. Probably same rationale applies here as for 32-bit Windows core dlls.
$ sha1sum googlechromestandaloneenterprise64.msi 586f91c05925e22fd5f891aa3e99e1cb9762950a googlechromestandaloneenterprise64.msi
$ du -sh googlechromestandaloneenterprise64.msi 47M googlechromestandaloneenterprise64.msi
$ wine --version wine-1.7.31-47-g516ed8e
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, win64 URL| |https://dl.google.com/dl/ch | |rome/install/googlechromest | |andaloneenterprise64.msi
https://bugs.winehq.org/show_bug.cgi?id=37585
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37585
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |loader Hardware|x86 |x86-64 Summary|64-bit Google Chrome 38.x |64-bit Chromium browser |crashes (core dlls must be |engine with native API |prelinked at fixed |sandboxing/hooking scheme |addresses) |fails if 64-bit | |ntdll.dll.so is not mapped | |at desired fixed address | |(Google Chrome 38+ crashes)
--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello folks,
still present, tested with 64-bit Chrome 46.0.2490.80
I'm refining the summary to indicate this includes all 64-bit apps/processes which make use of Chromium's browser engine with native API sandboxing/hooking scheme.
At least on my system, 64-bit 'ntdll.dll.so' can't be mapped at desired fixed <2GB address range since 'wine64' overlaps a bit into that area:
--- snip --- ... 00361000-68000000 ---p 00000000 00:00 0 7b800000-7b860000 r-xp 00000000 00:23 19715625 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7b860000-7b861000 rw-p 00000000 00:00 0 7b861000-7b935000 r-xp 00061000 00:23 19715625 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7b935000-7bb34000 ---p 00135000 00:23 19715625 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7bb34000-7bb35000 r--p 00134000 00:23 19715625 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7bb35000-7bce0000 rw-p 00135000 00:23 19715625 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7be00000-7bf02000 r-xp 00000000 00:23 19717163 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c000000-7c101000 rw-p 00000000 00:23 19717163 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c101000-7c102000 r--p 00101000 00:23 19717163 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c102000-7c103000 rw-p 00102000 00:23 19717163 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c400000-7c404000 r-xp 00200000 00:23 19717164 /home/focht/projects/wine/wine.repo/install/bin/wine64-preloader 7c604000-7c605000 rw-p 00204000 00:23 19717164 /home/focht/projects/wine/wine.repo/install/bin/wine64-preloader 7cadd000-7cbdf000 rw-p 00000000 00:00 0 [heap] 7ff00000-7ffe0000 ---p 00000000 00:00 0 7ffe0000-7fff0000 rw-p 00000000 00:00 0 317ae00000-317ae21000 r-xp 00000000 00:23 2123758 /usr/lib64/ld-2.21.so ... 7f4cd4942000-7f4cd49c0000 r-xp 00000000 00:23 19715856 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7f4cd49c0000-7f4cd49c1000 rw-p 00000000 00:00 0 7f4cd49c1000-7f4cd4abb000 r-xp 0007f000 00:23 19715856 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7f4cd4abb000-7f4cd4cba000 ---p 00179000 00:23 19715856 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7f4cd4cba000-7f4cd4cbb000 r--p 00178000 00:23 19715856 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7f4cd4cbb000-7f4cd4cc6000 rw-p 00179000 00:23 19715856 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7f4cd4cc6000-7f4cd4cde000 rw-p 00000000 00:00 0 --- snip ---
Relevant part of 'strace' log:
--- snip --- ... 2295 open("/home/focht/projects/wine/wine.repo/install/bin/wine64", O_RDONLY) = 3 2295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\20\r\360{\0\0\0\0"..., 2048) = 2048 2295 mmap(0x7be00000, 1056768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7be00000 2295 mmap(0x7c000000, 1060864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7c000000 2295 close(3) = 0 ... 2295 open("/home/focht/projects/wine/wine.repo/install/bin/../lib64/wine/ntdll.dll.so", O_RDONLY|O_CLOEXEC) = 3 2295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\5\310{\0\0\0\0"..., 832) = 832 2295 fstat(3, {st_dev=makedev(0, 43), st_ino=19715856, st_mode=S_IFREG|0755, st_nlink=1, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=6816, st_size=3488144, st_atime=2015/11/08-12:24:24, st_mtime=2015/11/07-11:36:52, st_ctime=2015/11/07-11:36:52}) = 0 2295 mmap(0x7bc00000, 3765184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0f85b87000 2295 mprotect(0x7f0f85d00000, 2093056, PROT_NONE) = 0 2295 mmap(0x7f0f85eff000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178000) = 0x7f0f85eff000 2295 mmap(0x7f0f85f0b000, 78784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0f85f0b000 2295 close(3) = 0 ... 2295 open("/home/focht/projects/wine/wine.repo/install/bin/../lib64/wine/kernel32.dll.so", O_RDONLY|O_CLOEXEC) = 6 2295 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340X\206{\0\0\0\0"..., 832) = 832 2295 fstat(6, {st_dev=makedev(0, 43), st_ino=19715625, st_mode=S_IFREG|0755, st_nlink=1, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8120, st_size=4155192, st_atime=2015/11/08-12:24:25, st_mtime=2015/11/07-11:36:47, st_ctime=2015/11/07-11:36:47}) = 0 2295 mmap(0x7b800000, 5109520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x7b800000 2295 mprotect(0x7b935000, 2093056, PROT_NONE) = 0 2295 mmap(0x7bb34000, 1753088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x134000) = 0x7bb34000 2295 close(6) ... --- snip ---
kernel32: 0x7b800000..0x7bf02000 (ok) ntdll: 0x7bc00000..0x7bf84000 (ought to be, can't be mapped here) wine64: 0x7be00000..0x7c103000 (has overlap into ntdll range, causing ntdll to be mapped in high 64-bit range)
If you move wine[64] load address a bit to higher range (don't forget to 'autoreconf -i' after modifying 'configure.ac') then 'ntdll.dll' can be properly mapped at desired fixed base address and 'ReadProcessMemory()' on remote process works as expected.
$ sha1sum googlechromestandaloneenterprise64.msi 778342857d42ae17a58bb4f60aea61aed2e7654f googlechromestandaloneenterprise64.msi
$ du -sh googlechromestandaloneenterprise64.msi 49M googlechromestandaloneenterprise64.msi
$ wine --version wine-1.7.54-179-ga0d0d0d
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@wine-staging | |.com
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello folks,
I've read some older mailing list posts and came around this:
https://www.winehq.org/pipermail/wine-devel/2015-November/110134.html
--- quote --- ... Most of this idea is in my patch 6 (https://dl.dropboxusercontent.com/u/195059/wine/ntdll-Syscall_Wrappers/0006-...), which I have tested with Steam pretty extensively. However, I cannot get the WoW64 version to "work" because of the 64-bit "webhelper" crap - for some reason it cannot read the 64-bit ntdll memory. --- quote ---
and
--- quote --- I have support for xp and xp-WoW64 in my prototype, the difficulty is that the xp-WoW64 doesn't work with Steam because of the 64-bit "helper". https://dl.dropboxusercontent.com/u/195059/wine/ntdll-Syscall_Wrappers/index...
The most interesting patches are 5 and 6, 7 is trying to figure out what is going on with the 64-bit version (it fails to even read the function memory at all). Michael has a brilliant scheme for getting the sysenter to work, but I'll leave that up to him to discuss. --- snip ---
Maybe you are encountering the problem that I have analysed here?
If it's a different problem and still present, please create another ticket and provide information how to exactly reproduce (or alternatively +server traces).
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #3 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Anastasius Focht from comment #2)
... Maybe you are encountering the problem that I have analysed here?
If it's a different problem and still present, please create another ticket and provide information how to exactly reproduce (or alternatively +server traces).
Regards
The problem does appear to be the same, I was unaware that you already had a bug for this. Do you know of an easy way to get the DLL mapped properly for testing?
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello Erich,
change the '.interp' section start in 'configure.ac' -> LOADER_RULES for '${wine_binary}':
https://source.winehq.org/git/wine.git/blob/79c852340c63a68c378c2059e1ffe73a...
--- snip --- ... 889 AS_VAR_APPEND([LOADER_RULES],[" 890 ${wine_binary}_OBJS = main.o 891 ${wine_binary}_LDFLAGS = $LDEXECFLAGS -lwine $(PTHREAD_LIBS) 892 "]) 893 ;; 894 895 *) ... 927 case $host_cpu in 928 *i[[3456789]]86* | x86_64) 929 WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x7bf00400], 930 [case $host_os in 931 freebsd* | kfreebsd*-gnu) LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x60000400" ;; 932 *) LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x7bf00400" ;; 933 esac 934 ]) ... --- snip ---
I moved the '.interp' section start a bit to 0x7c100400 which preserved the fixed load addresses on my system:
--- snip --- ... 00242000-00350000 rw-p 00000000 00:00 0 [stack:841] 00350000-00450000 ---p 00000000 00:00 0 00450000-68000000 ---p 00000000 00:00 0 7b800000-7b820000 r-xp 00000000 00:23 20372627 /home/focht/projects/wine/wine.repo/install/lib/wine/kernel32.dll.so 7b820000-7b821000 rw-p 00000000 00:00 0 7b821000-7b8c8000 r-xp 00021000 00:23 20372627 /home/focht/projects/wine/wine.repo/install/lib/wine/kernel32.dll.so 7b8c8000-7b8c9000 r--p 000c7000 00:23 20372627 /home/focht/projects/wine/wine.repo/install/lib/wine/kernel32.dll.so 7b8c9000-7ba73000 rw-p 000c8000 00:23 20372627 /home/focht/projects/wine/wine.repo/install/lib/wine/kernel32.dll.so 7bc00000-7bc30000 r-xp 00000000 00:23 20372872 /home/focht/projects/wine/wine.repo/install/lib/wine/ntdll.dll.so 7bc30000-7bc31000 rw-p 00000000 00:00 0 7bc31000-7bce9000 r-xp 00031000 00:23 20372872 /home/focht/projects/wine/wine.repo/install/lib/wine/ntdll.dll.so 7bce9000-7bcea000 r--p 000e8000 00:23 20372872 /home/focht/projects/wine/wine.repo/install/lib/wine/ntdll.dll.so 7bcea000-7bcf4000 rw-p 000e9000 00:23 20372872 /home/focht/projects/wine/wine.repo/install/lib/wine/ntdll.dll.so 7bcf4000-7bd07000 rw-p 00000000 00:00 0 7c100000-7c102000 r-xp 00000000 00:23 20374198 /home/focht/projects/wine/wine.repo/install/bin/wine 7c102000-7c103000 r--p 00001000 00:23 20374198 /home/focht/projects/wine/wine.repo/install/bin/wine 7c103000-7c104000 rw-p 00002000 00:23 20374198 /home/focht/projects/wine/wine.repo/install/bin/wine 7c400000-7c403000 r-xp 00001000 00:23 20374199 /home/focht/projects/wine/wine.repo/install/bin/wine-preloader 7c404000-7c405000 rw-p 00004000 00:23 20374199 /home/focht/projects/wine/wine.repo/install/bin/wine-preloader 7d458000-7d4f6000 rw-p 00000000 00:00 0 [heap] ... --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #5 from Anastasius Focht focht@gmx.net --- Hello again,
actually that was a process mapping dump with 32-bits (WoW), sorry.
With 64-bit loader you get ntdll at desired address but kernel32 got moved, so the final program loader location should be away further.
Since only 'ntdll' is of concern here, it's still good enough for testing.
--- snip --- ... 00360000-00361000 rw-p 00000000 00:00 0 00361000-68000000 ---p 00000000 00:00 0 7bc00000-7bc70000 r-xp 00000000 00:23 20366505 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7bc70000-7bc71000 rw-p 00000000 00:00 0 7bc71000-7bd7a000 r-xp 00071000 00:23 20366505 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7bd7a000-7bf79000 ---p 0017a000 00:23 20366505 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7bf79000-7bf7a000 r--p 00179000 00:23 20366505 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7bf7a000-7bf85000 rw-p 0017a000 00:23 20366505 /home/focht/projects/wine/wine.repo/install/lib64/wine/ntdll.dll.so 7bf85000-7bf99000 rw-p 00000000 00:00 0 7c000000-7c102000 r-xp 00000000 00:23 20367834 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c200000-7c301000 rw-p 00000000 00:23 20367834 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c301000-7c302000 r--p 00101000 00:23 20367834 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c302000-7c303000 rw-p 00102000 00:23 20367834 /home/focht/projects/wine/wine.repo/install/bin/wine64 7c400000-7c404000 r-xp 00200000 00:23 20367835 /home/focht/projects/wine/wine.repo/install/bin/wine64-preloader 7c604000-7c605000 rw-p 00204000 00:23 20367835 /home/focht/projects/wine/wine.repo/install/bin/wine64-preloader 7d021000-7d123000 rw-p 00000000 00:00 0 [heap] 7ff00000-7ffe0000 ---p 00000000 00:00 0 7ffe0000-7fff0000 rw-p 00000000 00:00 0 ... 7f1611ab7000-7f1611b10000 r-xp 00000000 00:23 20366279 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7f1611b10000-7f1611b11000 rw-p 00000000 00:00 0 7f1611b11000-7f1611bec000 r-xp 0005a000 00:23 20366279 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7f1611bec000-7f1611deb000 ---p 00135000 00:23 20366279 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7f1611deb000-7f1611dec000 r--p 00134000 00:23 20366279 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so 7f1611dec000-7f1611f97000 rw-p 00135000 00:23 20366279 /home/focht/projects/wine/wine.repo/install/lib64/wine/kernel32.dll.so --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #6 from Erich E. Hoover erich.e.hoover@wine-staging.com --- Hmm, still having trouble (yes, running autoreconf -i). What command did you run to confirm that things were being loaded in the right place? Sorry that I'm not familiar with this :/
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello Erich,
quickest method without attaching debugger: 'cat /proc/<pid>/maps' on each 'webhelper' process.
To check if and how remapping happens at startup: 'strace -vf -o strace.log wine64 foo ...' (follow fork option for childs).
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #8 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Anastasius Focht from comment #7)
Hello Erich,
quickest method without attaching debugger: 'cat /proc/<pid>/maps' on each 'webhelper' process.
To check if and how remapping happens at startup: 'strace -vf -o strace.log wine64 foo ...' (follow fork option for childs).
Regards
It looks like the normal browser is fine but the WoW64 helper is off in the weeds: https://dl.dropboxusercontent.com/u/195059/wine/ntdll-Syscall_Wrappers/webma... https://dl.dropboxusercontent.com/u/195059/wine/ntdll-Syscall_Wrappers/wowma...
$ cat wowmap.txt | grep -i -e ntdll -e kernel32 7b800000-7b820000 r-xp 00000000 08:01 21669387 /usr/local/lib64/wine/kernel32.dll.so 7b821000-7b8d3000 r-xp 00021000 08:01 21669387 /usr/local/lib64/wine/kernel32.dll.so 7b8d3000-7bad2000 ---p 000d3000 08:01 21669387 /usr/local/lib64/wine/kernel32.dll.so 7bad2000-7bad4000 r--p 000d2000 08:01 21669387 /usr/local/lib64/wine/kernel32.dll.so 7bad4000-7bc7f000 rwxp 000d4000 08:01 21669387 /usr/local/lib64/wine/kernel32.dll.so 7f258c576000-7f258c590000 r-xp 00000000 08:01 21658147 /usr/local/lib64/wine/ntdll.dll.so 7f258c591000-7f258c668000 r-xp 0001b000 08:01 21658147 /usr/local/lib64/wine/ntdll.dll.so 7f258c668000-7f258c868000 ---p 000f2000 08:01 21658147 /usr/local/lib64/wine/ntdll.dll.so 7f258c868000-7f258c869000 r--p 000f2000 08:01 21658147 /usr/local/lib64/wine/ntdll.dll.so 7f258c869000-7f258c875000 rwxp 000f3000 08:01 21658147 /usr/local/lib64/wine/ntdll.dll.so
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #9 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Erich E. Hoover from comment #8)
...
Ok, figured it out. It wasn't doing a rebuild of wine64, after touching loader/main.c it's in the right place and it can read the memory (hurray!). Something else is going on that prevents it from continuing, but at least now the memory is being read correctly. Is there some reason wine64 isn't mapped at this address to start with? It seems like it should be mapped so that it doesn't interfere with ntdll...
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello Erich,
--- quote --- Is there some reason wine64 isn't mapped at this address to start with? It seems like it should be mapped so that it doesn't interfere with ntdll... --- quote ---
well, that's something to ask Alexandre about.
That part of the fixed address space layout hasn't been changed/touched for a while. The area where both core dlls ought to be mapped is one of the few fixed ranges, hence putting the wine ELF binary there too to avoid collisions with other (later) reserved areas and potentially avoid address space fragmentation might be a natural choice. Maybe I'm wrong and there is a different technical constraint why the interpreter section address is exactly there.
At introduction time of the fixed (prelink) addresses the target was clearly 32-bits (to cope with those brain damaged copy protection schemes). No one thought about 64-bit having similar problem - until now ;-)
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #11 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Anastasius Focht from comment #10)
Hello Erich,
--- quote --- Is there some reason wine64 isn't mapped at this address to start with? It seems like it should be mapped so that it doesn't interfere with ntdll... --- quote ---
well, that's something to ask Alexandre about. ...
Alright, I'll have to do that :) It looks like chrome is expecting the 64-bit ntdll to be mapped into the address space of the 32-bit app, so ... fixing this is looking like a real mess.
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello Erich,
--- quote --- It looks like chrome is expecting the 64-bit ntdll to be mapped into the address space of the 32-bit app --- quote ---
MSDN details: https://msdn.microsoft.com/en-us/library/aa384274%28v=vs.85%29.aspx
--- quote --- The WOW64 emulator runs in user mode. It provides an interface between the 32-bit version of Ntdll.dll and the kernel of the processor, and it intercepts kernel calls. The WOW64 emulator consists of the following DLLs:
* Wow64.dll provides the core emulation infrastructure and the thunks for the Ntoskrnl.exe entry-point functions. * Wow64Win.dll provides thunks for the Win32k.sys entry-point functions. * Wow64Cpu.dll is an interface library that abstracts characteristics of the host processor. ...
These DLLs, along with the 64-bit version of Ntdll.dll, are the only 64-bit binaries that can be loaded into a 32-bit process.
At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its initialization code, which loads all necessary 32-bit DLLs. Almost all 32-bit DLLs are unmodified copies of 32-bit Windows binaries. However, some of these DLLs are written to behave differently on WOW64 than they do on 32-bit Windows, usually because they share memory with 64-bit system components. All user-mode address space above the 32-bit limit is reserved by the system. For more information, see Performance and Memory Consumption under WOW64.
Instead of using the x86 system-service call sequence, 32-bit binaries that make system calls are rebuilt to use a custom calling sequence. This calling sequence is inexpensive for WOW64 to intercept because it remains entirely in user mode. When the custom calling sequence is detected, the WOW64 CPU transitions back to native 64-bit mode and calls into Wow64.dll. Thunking is done in user mode to reduce the impact on the 64-bit kernel and to reduce the risk of a bug in the thunk that might cause a kernel-mode crash, data corruption, or a security hole. The thunks extract arguments from the 32-bit stack, extend them to 64 bits, then make the native system call. --- quote ---
Reading the Chromium project change history it seems the WoW helper process mechanism is only supported/implemented for OS <= Windows Vista anyway.
--- quote --- fixing this is looking like a real mess. --- quote ---
I tend to say "not worth the damage". At one point Wine will default to Winver "Windows 7" anyway and the sandboxing schemes employ different methods then.
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #13 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Anastasius Focht from comment #12)
... Reading the Chromium project change history it seems the WoW helper process mechanism is only supported/implemented for OS <= Windows Vista anyway.
--- quote --- fixing this is looking like a real mess. --- quote ---
I tend to say "not worth the damage". At one point Wine will default to Winver "Windows 7" anyway and the sandboxing schemes employ different methods then.
Looks like you're right, the helper processes is only used <=Vista: https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239c2a3c2f2364da996...
That possibly gives us an avenue for supporting this without making a giant mess. The 32-bit and WoW64 thunks are not horrible, so with a little digging we may be able to support Win7 mode.
https://bugs.winehq.org/show_bug.cgi?id=37585
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
https://bugs.winehq.org/show_bug.cgi?id=37585
Danny Rawlins monster.romster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |monster.romster@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37585
--- Comment #14 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 53875 --> https://bugs.winehq.org/attachment.cgi?id=53875 backtrace with .interp=0x7c100400 (wine 1.9.5)
Even with .interp set to 0x7c100400 in configure.ac, and autoreconf -i, I still get the same unhandled page fault than without changing the .interp address.
I compile both 32 and 64bit wine with .interp set to 0x7c100400. Does it work like this or should I change .interp only for the 64bit part in a shared wow64 setup?
https://bugs.winehq.org/show_bug.cgi?id=37585
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37585
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |1df3955467edb13c1cf6929ac55 | |f29fd91b0eecc Resolution|--- |FIXED URL|https://dl.google.com/dl/ch |https://web.archive.org/web |rome/install/googlechromest |/20151209125613/https://dl. |andaloneenterprise64.msi |google.com/dl/chrome/instal | |l/googlechromestandaloneent | |erprise64.msi Summary|64-bit Chromium browser |64-bit Chromium browser |engine with native API |engine with native API |sandboxing/hooking scheme |sandboxing/hooking scheme |fails if 64-bit |fails if 64-bit |ntdll.dll.so is not mapped |ntdll.dll.so is not mapped |at desired fixed address |at desired fixed address |(Google Chrome 38+ crashes) |(Google Chrome 38+ crashes | |with WinVer <= Vista)
--- Comment #15 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting. This was actually mitigated/fixed by a change from Alexandre which aimed to solve a different problem: https://source.winehq.org/git/wine.git/commitdiff/1df3955467edb13c1cf6929ac5... ("makefiles: Move the main loader base address to cope with huge page alignment.").
-> wine-1.9.10
--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/Google/Chrome/Application
$ WINEDEBUG=+tid,+seh,+relay,+server,+virtual,+module wine64 ./chrome.exe
log.txt 2>&1
... 0045:Call KERNEL32.VirtualAllocEx(00000454,00000000,0000006c,00001000,00000004) ret=140048eb7 0045:trace:virtual:NtAllocateVirtualMemory 0x454 (nil) 0000006c 1000 00000004 0045: queue_apc( handle=0454, call={APC_VIRTUAL_ALLOC,addr==00000000,size=0000006c,zero_bits=0,op_type=1000,prot=4} ) 0066: *wakeup* signaled=192 0045: queue_apc() = 0 { handle=0448, self=0 } 0066: select( flags=2, cookie=0022e404, timeout=1d4d7f43a8f0412 (-0.0017100), prev_apc=0000, result={}, data={} ) 0066: select() = USER_APC { timeout=1d4d7f43a8f0412 (-0.0017100), call={APC_VIRTUAL_ALLOC,addr==00000000,size=0000006c,zero_bits=0,op_type=1000,prot=4}, apc_handle=0020 } 0045: select( flags=2, cookie=062cd774, timeout=infinite, prev_apc=0000, result={}, data={WAIT_ALL,handles={0448}} ) 0066:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 0000006c 1000 00000004 0045: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 } 0066:trace:virtual:map_view got mem in reserved area 0x230000-0x231000 0066:trace:virtual:VIRTUAL_DumpView View: 0x230000 - 0x230fff (valloc) 0066:trace:virtual:VIRTUAL_DumpView 0x230000 - 0x230fff c-rw- 0066: select( flags=2, cookie=0022e404, timeout=1d4d7f43a8f0412 (-0.0017740), prev_apc=0020, result={APC_VIRTUAL_ALLOC,status=0,addr=00230000,size=00001000}, data={} ) 0045: *wakeup* signaled=0 0066: select() = PENDING { timeout=1d4d7f43a8f0412 (-0.0017740), call={APC_NONE}, apc_handle=0000 } 0045: get_apc_result( handle=0448 ) 0045: get_apc_result() = 0 { result={APC_VIRTUAL_ALLOC,status=0,addr=00230000,size=00001000} } 0045:Ret KERNEL32.VirtualAllocEx() retval=00230000 ret=140048eb7 0045:Call KERNEL32.WriteProcessMemory(00000454,00230000,04993650,0000006c,062cdea0) ret=140048edb 0045: write_process_memory( handle=0454, addr=00230000, data={01,00,00,00,00,00,00,00,00,00,00,00,60,00,00,00,00,00,00,00,30,00,00,00,00,00,00,00,01,00,00,00,00,36,6b,00,65,00,72,00,6e,00,65,00,6c,00,33,00,32,00,2e,00,64,00,6c,00,6c,00,00,00,30,00,00,00,00,00,00,00,02,00,00,00,0e,00,00,00,f8,12,05,40,01,00,00,00,43,72,65,61,74,65,4e,61,6d,65,64,50,69,70,65,57,00,00,00,00,10,00,00,00} ) 0066: *signal* signal=19 0045: write_process_memory() = 0 0045:Ret KERNEL32.WriteProcessMemory() retval=00000001 ret=140048edb ... 0045:Call KERNEL32.ReadProcessMemory(00000454,7bc8daa0,062cdb50,00000020,062cdb80) ret=1400519cc 0045: read_process_memory( handle=0454, addr=7bc8daa0 ) 0066: *signal* signal=19 0045: read_process_memory() = 0 { data={4c,89,4c,24,20,4c,89,44,24,18,48,89,54,24,10,48,89,4c,24,08,ba,64,00,03,00,48,8d,0d,e8,f9,12,00} } 0045:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=1400519cc ... --- snip ---
Relevant part of 64-bit target process address space:
--- snip --- ... 7b400000-7b460000 r-xp 00000000 fd:03 21135270 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/kernel32.dll.so 7b460000-7b461000 rw-p 00000000 00:00 0 7b461000-7b6db000 r-xp 00061000 fd:03 21135270 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/kernel32.dll.so 7b6db000-7b6dc000 ---p 002db000 fd:03 21135270 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/kernel32.dll.so 7b6dc000-7b6dd000 r--p 002db000 fd:03 21135270 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/kernel32.dll.so 7b6dd000-7b899000 rw-p 002dc000 fd:03 21135270 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/kernel32.dll.so 7bc00000-7bc80000 r-xp 00000000 fd:03 21135535 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/ntdll.dll.so 7bc80000-7bc81000 rw-p 00000000 00:00 0 7bc81000-7bdb2000 r-xp 00081000 fd:03 21135535 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/ntdll.dll.so 7bdb2000-7bdb3000 r--p 001b1000 fd:03 21135535 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/ntdll.dll.so 7bdb3000-7bdbf000 rw-p 001b2000 fd:03 21135535 /home/focht/projects/wine/mainline-install-x86_64/lib64/wine/ntdll.dll.so 7bdbf000-7bdd2000 rw-p 00000000 00:00 0 7c000000-7c002000 r-xp 00000000 fd:03 21269859 /home/focht/projects/wine/mainline-install-x86_64/bin/wine64 7c002000-7c003000 r--p 00001000 fd:03 21269859 /home/focht/projects/wine/mainline-install-x86_64/bin/wine64 7c003000-7c004000 rw-p 00002000 fd:03 21269859 /home/focht/projects/wine/mainline-install-x86_64/bin/wine64 7c400000-7c403000 r-xp 00200000 fd:03 21269886 /home/focht/projects/wine/mainline-install-x86_64/bin/wine64-preloader 7c603000-7c604000 rw-p 00203000 fd:03 21269886 /home/focht/projects/wine/mainline-install-x86_64/bin/wine64-preloader 7cef8000-7d0c7000 rw-p 00000000 00:00 0 [heap] 7ff00000-7ffe0000 ---p 00000000 00:00 0 7ffe0000-7fff0000 rw-p 00000000 00:00 0 140000000-140001000 r--p 00000000 fd:03 1723494 /home/focht/.wine/drive_c/Program Files (x86)/Google/Chrome/Application/chrome.exe 140001000-14007b000 r-xp 00000000 00:00 0 14007b000-140096000 r--p 00000000 00:00 0 140096000-140099000 rw-p 00094000 fd:03 1723494 /home/focht/.wine/drive_c/Program Files (x86)/Google/Chrome/Application/chrome.exe 140099000-14009d000 rw-p 00000000 00:00 0 14009d000-1400a4000 r--p 00000000 00:00 0 1400a4000-1400a5000 rw-p 00000000 00:00 0 1400a5000-1400ca000 r--p 00000000 00:00 0 180000000-180001000 r--p 00000000 fd:03 1723394 /home/focht/.wine/drive_c/Program Files (x86)/Google/Chrome/Application/47.0.2526.80/chrome_elf.dll 180001000-180016000 r-xp 00000000 00:00 0 180016000-180021000 r--p 00000000 00:00 0 180021000-180026000 rw-p 00000000 00:00 0 180026000-180028000 r--p 00000000 00:00 0 180028000-180029000 r-xp 00022000 fd:03 1723394 /home/focht/.wine/drive_c/Program Files (x86)/Google/Chrome/Application/47.0.2526.80/chrome_elf.dll 180029000-18002a000 r-xp 00000000 00:00 0 18002a000-18002c000 r--p 00000000 00:00 0 ... --- snip ---
$ sha1sum googlechromestandaloneenterprise64.msi 0c0e2b96bf56dadfe603930956b7165621fa44a0 googlechromestandaloneenterprise64.msi
$ du -sh googlechromestandaloneenterprise64.msi 50M googlechromestandaloneenterprise64.msi
$ wine --version wine-4.3-229-g6d82b2f1ad
Regards
https://bugs.winehq.org/show_bug.cgi?id=37585
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.4.
-
wine-bugs＠winehq.org