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/1fa7710ff92dd9555b2b4753e22ce5f…
--- 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.
http://bugs.winehq.org/show_bug.cgi?id=32237
Bug #: 32237
Summary: A slower speed of light: Game crashes after Intro
Product: Wine
Version: 1.5.14
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fox6x6x6(a)gmail.com
Classification: Unclassified
Created attachment 42525
--> http://bugs.winehq.org/attachment.cgi?id=42525
wine output
The game starts normally and you can watch the Intro, but after that the game
crashes.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
http://bugs.winehq.org/show_bug.cgi?id=29128
Bug #: 29128
Summary: L.A. Noire fails to launch
Product: Wine
Version: 1.3.33
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: peanuthead_069(a)yahoo.com
Classification: Unclassified
Created attachment 37529
--> http://bugs.winehq.org/attachment.cgi?id=37529
Terminal log of launch attempt.
Well, since no one seems to have tested this game yet, I decided to take
matters into my own hands. The installer now works on 1.3.33, but the game
itself doesn't. All the necessary dependencies are installed already, but still
even the mandatory patch required to activate and launch the game doesn't work.
Even the no-spaces workaround when installing the game showed no signs of the
Noire launching.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=39847
Bug ID: 39847
Summary: Installation ABBYY Aligner2
Product: Wine
Version: 1.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: msrom(a)mail.ru
Distribution: ---
Created attachment 53196
--> https://bugs.winehq.org/attachment.cgi?id=53196
log
Cannot install application ABBYY Aligner2
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44077
Bug ID: 44077
Summary: Overwatch: Within the first minute of game play the
entire OS stops rendering (requires hard reboot)
Product: Wine-staging
Version: 2.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sander.smid(a)gmail.com
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
wine-2.21 (Staging)
Linux oribi 4.13.12-1-ARCH #1 SMP PREEMPT Wed Nov 8 11:54:06 CET 2017 x86_64
GNU/Linux
Graphics: Card: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX
470/480/570/580]
Display Server: x11 (X.Org 1.19.5 ) drivers: nvidia (unloaded:
modesetting,fbdev,nv,vesa,nouveau)
Resolution: 1920x1200(a)59.95hz
OpenGL: renderer: AMD Radeon RX 480 Graphics (AMD POLARIS10 / DRM
3.18.0 / 4.13.12-1-ARCH, LLVM 5.0.0)
version: 4.5 Mesa 17.2.5
env WINEPREFIX="/games/BattleNet" /usr/bin/wine
/games/BattleNet/drive_c/Program\ Files\ \(x86\)/Overwatch/Overwatch.exe
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44089
Bug ID: 44089
Summary: Strider crashes after loading screen
Product: Wine
Version: 2.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3dx11
Assignee: wine-bugs(a)winehq.org
Reporter: strider(a)strycore.com
Distribution: ---
Created attachment 59805
--> https://bugs.winehq.org/attachment.cgi?id=59805
backtrace of the crash
While the main menu works fine, when starting a game, the game crashes. This is
a regression that started in Wine Staging 2.16, when the deferred context patch
(https://dev.wine-staging.com/patches/181/) was introduced. I had a build of
Wine Staging 2.15 with that patch enabled and I noticed crashes starting with
that build and onward until the latest tested, Staging 2.21.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=18104
Summary: Final Draft: text to speech fails
Product: Wine
Version: 1.1.19
Platform: All
URL: http://www.finaldraft.com/downloads/demo-final-draft.php
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jens(a)porup.com
Final Draft is the screenwriter's standard word processor.
It offers a text to speech feature that does not work in wine. It doesn't break
anything if you try; the buttons just don't do anything at all.
Terminal output coming soon.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=42136
Bug ID: 42136
Summary: switching tab in sapi.cpl crashes control
Product: Wine
Version: 2.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fiendishx(a)gmail.com
Distribution: ---
Created attachment 56693
--> https://bugs.winehq.org/attachment.cgi?id=56693
console log
sapi.cpl is installed by the Microsoft Speech SDK installer from
https://download.microsoft.com/download/B/4/3/B4314928-7B71-4336-9DE7-6FA4C…
(or via winetricks)
$ wine control '.wine/drive_c/Program Files (x86)/Common Files/Microsoft
Shared/Speech/sapi.cpl'
brings up the Speech Properties control panel.
Choosing the tab labeled "Text To Speech" crashes the control. Console log
attached.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40502
Bug ID: 40502
Summary: Global objects constructors fail when invoking
standard libs
Product: Wine
Version: 1.8.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: winelib
Assignee: wine-bugs(a)winehq.org
Reporter: mirko.ortensi(a)gmail.com
Distribution: ---
I managed to recompile and link my win32 application but at execution time, it
crashes because of a segmentation fault where memset (or the bare
printf("HELLO")) is invoked in the global object constructor (any call to
standard C library is enough to trigger the crash).
The global object is built in the stack, then it seems that at launch time my
object constructor is called before C Standard Library is ready.
Now, as a workaround I can declare a pointer to global object and instantiate
it in the main (tested, it works)...though...this is something I'd like to
avoid to keep the code as original as possible. Removing the global objects,
everything works like a charm.
As far as I understand, global object constructors are called after Wine
infrastructure is ready to go, though I have doubts now regarding C Standard
Library.
(Please check 8.3.3. Starting a Winelib process
https://www.winehq.org/docs/winedev-guide/x3172)
This code reproduces the error:
#include <stdio.h>
class Printer
{
public:
Printer(){printf("HI\n");}
};
Printer p;
int main(void)
{
return 0;
}
The issue is reproduced by this code linking to msvcrt:
wineg++ -mno-cygwin issue.cpp -o issue
Linking to system libs, this code does not reproduce the issue.
wineg++ issue.cpp -o issue
Now, in my code (pretty big software I am porting to Linux) I still need to
isolate root cause, issue is reproduced even linking against system libraries
(not Wine's msvcrt, then). Anyway, I think there's a bug somewhere when linking
to msvcrt even in this silly piece of code.
--
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.