https://bugs.winehq.org/show_bug.cgi?id=39570 Bug ID: 39570 Summary: Multiple application crash handlers fail to load symbol information using 'dbghelp.SymLoadModule64', reporting 'dbghelp:validate_addr64 Unsupported address 0xfffffffffxxxxxxx' Product: Wine Version: 1.7.54 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, the issue/question was raised in https://bugs.winehq.org/show_bug.cgi?id=32237#c15 --- quote --- I did try 2012 this time and I end up crashing fixme:dbghelp:validate_addr64 Unsupported address fffffffff33a0000 err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7bc3db51 What's wrong with the address? --- quote --- Searching the Internet reveals this pattern/message many times - also in Wine Bugzilla - but no or even incorrect explanation - until now ;-) On 64-bit Linux machines, the Wine loader allows 32-bit dlls being mapped at high >2GB, >3GB address ranges in 32-bit processes, not having certain (design) restrictions of 32-bit process address space layout on 64-bit Windows machines (even with /LARGEADDRESSWARE). Good case, 32-bit Wine builtin dll mapped < 2 GiB virtual address space range: --- snip --- ... 0009:Call PE DLL (proc=0x7e1b6838,module=0x7e1b0000 L"wsock32.dll",reason=PROCESS_ATTACH,res=0x1) ... 0027:Call dbghelp.SymLoadModule64(ffffffff,00000000,0b36a960 "C:\\windows\\system32\\wsock32.dll",0b36a988 "wsock32.dll",7e1b0000,00000000,0000e000) ret=005eff32 0027:trace:dbghelp:SymLoadModuleEx (0xffffffff (nil) "C:\\windows\\system32\\wsock32.dll" "wsock32.dll" 7e1b0000 0000e000 (nil) 00000000) ... 0027:trace:dbghelp:SymLoadModuleExW (0xffffffff (nil) L"C:\\windows\\system32\\wsock32.dll" L"wsock32.dll" 7e1b0000 0000e000 (nil) 00000000) ... 0027:trace:dbghelp:elf_load_file Processing elf file 'L"/home/focht/projects/wine/wine.repo/install/bin/../lib/wine/wsock32.dll.so"' at 7e1a2000 ... 0027:Ret dbghelp.SymLoadModule64() retval=7e1b0000 ret=005eff32 --- snip --- Bad case, 32-bit Wine builtin dll mapped near end of 4 GiB virtual address space range: --- snip --- ... 0009:Call PE DLL (proc=0xf734e3fc,module=0xf72f0000 L"winex11.drv",reason=PROCESS_ATTACH,res=(nil)) ... 0027:Call dbghelp.SymLoadModule64(ffffffff,00000000,0b36a960 "C:\\windows\\system32\\winex11.drv",0b36a988 "winex11.drv",f72f0000,ffffffff,00090000) ret=005eff32 0027:trace:dbghelp:SymLoadModuleEx (0xffffffff (nil) "C:\\windows\\system32\\winex11.drv" "winex11.drv" fffffffff72f0000 00090000 (nil) 00000000) "winex11.drv",ffffffff,2d053b40,0000000c) ret=edbc2fa6 ... 0027:trace:dbghelp:SymLoadModuleExW (0xffffffff (nil) L"C:\\windows\\system32\\winex11.drv" L"winex11.drv" fffffffff72f0000 00090000 (nil) 00000000) 0027:fixme:dbghelp:validate_addr64 Unsupported address fffffffff72f0000 ... 0027:Ret dbghelp.SymLoadModule64() retval=00000000 ret=005eff32 --- snip --- In this specific case, the game registered an own crash handler which dumps various debugging information in case of a crash. 'dbghelp.SymLoadModule64' is called by the custom crash handler. Source: https://source.winehq.org/git/wine.git/blob/1fa7710ff92dd9555b2b4753e22ce5fc... --- snip --- 656 DWORD64 WINAPI SymLoadModule64(HANDLE hProcess, HANDLE hFile, PCSTR ImageName, 657 PCSTR ModuleName, DWORD64 BaseOfDll, DWORD SizeOfDll) 658 { 659 return SymLoadModuleEx(hProcess, hFile, ImageName, ModuleName, BaseOfDll, SizeOfDll, 660 NULL, 0); 661 } --- snip --- So how does high DWORD of 'BaseOfDll' parameter get the 0xffffffff value? A few caller frames up in the app crash handler: --- snip --- ... 005F06D6 8B55 D0 MOV EDX,DWORD PTR SS:[EBP-30] 005F06D9 8B45 CC MOV EAX,DWORD PTR SS:[EBP-34] 005F06DC 8B4D F8 MOV ECX,DWORD PTR SS:[EBP-8] 005F06DF 52 PUSH EDX 005F06E0 99 CDQ 005F06E1 52 PUSH EDX ; high DWORD BaseOfDll 005F06E2 50 PUSH EAX ; low DWORD BaseOfDll 005F06E3 8B45 FC MOV EAX,DWORD PTR SS:[EBP-4] 005F06E6 50 PUSH EAX 005F06E7 51 PUSH ECX 005F06E8 8B4D E8 MOV ECX,DWORD PTR SS:[EBP-18] 005F06EB 56 PUSH ESI 005F06EC E8 EFF7FFFF CALL A_Slower.005EFEE0 ... --- snip --- 'winex11.drv' -> 0xf72f0000 Since the highest bit in low 32-bit 'BaseOfDll' DWORD is set, the 'CDQ' instruction copies the sign (bit 31) of the value in the EAX register into every bit position in the EDX register. Voila - you get the 0xffffffff EDX value which is then propagated through the caller chain as high 32-bit 'BaseOfDll' DWORD to 'dbghelp.SymLoadModule64', leading to symbol load failure and fixme/warning messages. This should be fixed, allowing symbol information even for dlls mapped in high address range to be loaded. $ wine --version wine-1.7.54-261-g61c49bd Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.