https://bugs.winehq.org/show_bug.cgi?id=54659
Bug ID: 54659
Summary: d3d8:device & d3d9:device sometimes get floating point
underflow in GenerateRampFromGamma() in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
d3d8:device & d3d9:device sometimes get an floating point underflow exception
in GenerateRampFromGamma() in Wine:
d3d8:device start dlls/d3d8/tests/device.c
Unhandled exception: floating point underflow in 32-bit code (0x7e91438f).
[...]
Backtrace:
=>0 0x7e91438f in libm.so.6 (+0x2538f) (0x0069ef68)
1 0x7e922d3b in libm.so.6 (+0x33d3b) (0x0069ef68)
2 0x7e55c181 GenerateRampFromGamma+0x51(ramp=00197C4C, gamma=0.000300)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:336] in
winex11.so (0x0069ef68)
3 0x7e55c9b2 X11DRV_XF86VM_GetGammaRamp+0x60(ramp=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:519] in
winex11.so (0x0069ef68)
4 0x7e55c9b2 X11DRV_GetDeviceGammaRamp+0x82(dev=<couldn't compute location>,
ramp=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:569] in
winex11.so (0x0069ef68)
5 0x7ea32408 NtGdiGetDeviceGammaRamp+0x88(hdc=<couldn't compute location>,
ptr=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\win32u\dc.c:1247] in win32u.so
(0x0069efb8)
6 0x64a8d74c NtGdiGetDeviceGammaRamp+0x2c(hdc=<couldn't compute location>,
ptr=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\win32u\wrappers.c:280] in win32u
(0x0069efe8)
7 0x6ccf9d3d wined3d_output_get_gamma_ramp+0x4d(output=00140E10,
ramp=00197C4C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\directx.c:1741] in
wined3d (0x0069f028)
8 0x6cd5fcb0 wined3d_swapchain_get_gamma_ramp+0x30(swapchain=00197C30,
ramp=00197C4C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:385] in
wined3d (0x0069f058)
9 0x6cd61190 wined3d_swapchain_init+0x3c0(swapchain=<register EBX not
accessible in this frame>, device=<register EDI not accessible in this frame>,
desc=<internal error>, state_parent=00140D5C, parent=00140D50,
parent_ops=67CDE7D4, swapchain_ops=6CE6933C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:1633] in
wined3d (0x0069f168)
10 0x6cc8d9f3 adapter_gl_create_swapchain+0x73(device=0017B3E8,
desc=0069F2BC, state_parent=00140D5C, parent=00140D50, parent_ops=67CDE7D4,
swapchain=0069F1FC)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\adapter_gl.c:4701] in
wined3d (0x0069f1b8)
11 0x6cd5fdd1 wined3d_swapchain_create+0x41(device=0017B3E8, desc=0069F2BC,
state_parent=00140D5C, parent=00140D50, parent_ops=67CDE7D4,
swapchain=00140D58)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:1724] in
wined3d (0x0069f208)
12 0x67ccfe84 swapchain_init+0x48(swap_interval=<internal error>,
desc=<internal error>, device=<internal error>, swapchain=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\swapchain.c:180] in d3d8
(0x0069f248)
13 0x67ccfe84 d3d8_swapchain_create+0x84(device=001468F0, desc=0069F2BC,
swap_interval=0xffffffff, swapchain=0069F290)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\swapchain.c:199] in d3d8
(0x0069f248)
14 0x67ccc467 device_init+0x217(device=001468F0, parent=00140A90,
wined3d=00140AB0, adapter=0, device_type=D3DDEVTYPE_HAL, focus_window=0003004A,
flags=0x42, parameters=0069F53C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\device.c:3744] in d3d8
(0x0069f478)
15 0x67ccd649 d3d8_CreateDevice+0xa9(iface=<couldn't compute location>,
adapter=<couldn't compute location>, device_type=<couldn't compute location>,
focus_window=<couldn't compute location>, flags=<couldn't compute location>,
parameters=<couldn't compute location>, device=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\directx.c:438] in d3d8
(0x0069f4e8)
16 0x004010ce in d3d8_test (+0x10ce) (0x0069f588)
...
This does not happen in the nightly Wine test runs but impacted at least two
merge requests:
* MR2072, repeatedly
* MR2217, repeatedly
There are three immediate questions:
* Where does the 0.000300 gamma come from?
I don't think such a value makes sense so I suspect it's caused by a bug
somewhere.
* Should xvidmode.c's GenerateRampFromGamma() crash in case of underflow (or
overflow for that matter)?
If not, ComputeGammaFromRamp() should probably be fixed too. Which other
functions have the same issue? (not just in xvidmode.c)
* By default underflows don't cause exceptions. So which piece of code in
d3d8:device does a _control87(0, _EM_UNDERFLOW) ?
Then, why does this failure not happen more often?
The debian11 VM ran the tests multiple times in a row to test various locales:
en -> success
ar:MA -> success
de -> success
fr -> underflow
he:IL -> underflow
hi:IN -> underflow
ja:JP -> underflow
zh:CN -> underflow
While the wineprefix is recreated for each test, all the tests run on the same
X server session. So my theory is that one of the tests in the first three runs
progressively degraded the gamma at the X level, such that all the tests that
followed got a bad gamma from the X server and crashed. Furthermore note that
the first plain 32-bit run ran the full Wine test suite. That may have been a
factor too.
MR2217 caused the following tests to run so the guilty party should be among
them:
d3d8:device d3d9:device ddraw:ddraw1 ddraw:ddraw2 ddraw:ddraw4 ddraw:ddraw7
That explains why this failure does not happen in the nightly Wine test runs:
each is done after restoring the VM to a clean state. Similarly, other merge
requests may run fewer tests so that the gamma does not get degraded that much.
That leaves a mystery though: I don't get this issue on my desktop (fg-deb64)
despite running the tests every night and not ever restarting the X server
(thankfully!). Maybe this gamma issue is caused by a bug that only happens with
the VM environment (likely QXL GPU or dual screen configuration, such that it
does not happen on single-screen Intel GPUs)?
--
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=53553
Bug ID: 53553
Summary: F.E.A.R. won't work with DSOAL surround sound
restoration DLL replacement
Product: Wine
Version: 7.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dsound
Assignee: wine-bugs(a)winehq.org
Reporter: mr.matt.eastwood(a)gmx.de
Distribution: ---
Steps to Reproduce:
1. Install F.E.A.R. (e.g., "Fear Platinum" from GOG)
2. Get DSOAL from https://github.com/kcat/dsoal and compile dsound.dll
3. Get latest OpenAL-Soft bin from https://openal-soft.org/
4. Unzip soft_oal.dll from its bin\Win32 directory
5. Rename that file to dsoal-aldrv.dll
6. Place both dsoal-aldrv.dll and DSOAL's dsound.dll in same directory as
FEAR.exe
7. Run game
8. Enter sound menu
Expected Results:
When running F.E.A.R. with the DLL replacement DSOAL for surround sound
restoration, the advanced sound options "Enable HW mixing", "Enable EAX 2.0"
and "Enable EAX Advanced HD" should be available in the sound menu and surround
sound including EAX effects should work.
Current Results:
The sound options remain greyed-out.
Observations:
F.E.A.R. won't load dsound.dll from anywhere but syswow64. If one places the
DSOAL dsound.dll there (replacing Wine's own), and then sets dsound.dll to
"native" e.g. through winecfg, everything works. Screenshot:
If one sets dsound.dll to "native" e.g. through winecfg and then loads the game
without replacing Wine's dsound.dll in syswow64 (but with the DSOAL files in
the F.E.A.R. folder): "Failed to initialize sound driver 'SndDrv.dll' on
startup. Screenshot: https://paste.pics/I4DO0. No sound during game or menus,
only during intro movie. Available sound options: https://paste.pics/I4DOD
--
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=49915
Bug ID: 49915
Summary: can not register COM server
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ysong2180(a)yahoo.com
Distribution: ---
Created attachment 68286
--> https://bugs.winehq.org/attachment.cgi?id=68286
two log files. one is the winecfg log. The other one is the application log
I tried to install an windows application on Ubuntu 20.04. The installer can
run and install files. But it fails at the end when it tries to register COM
servers. It is a win32 application. I used winecfg to create a win32
wineprefix and used the win32 wineprefix to start the installer.
--
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=54677
Bug ID: 54677
Summary: Wine cannot find tools in tool dir when cross
compiling
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: ale.schenberg(a)yandex.com
Distribution: ---
Created attachment 74193
--> https://bugs.winehq.org/attachment.cgi?id=74193
config.log
Hello. When trying to cross build wine, configure's execution breaks due to it
to not find wine tools in the tools dir.
My building command:
LDFLAGS=-Wl,--dynamic-link=/usr/lib32/ld-2.17.so ./configure
--host=i686-gnu-linux --with-wine-tools=tools/
I attached config.log, although it appears to contain no useful information.
The bug applies to wine 8.3 and any other wine version that I tested (such as
1.9)
I think its worthy to mention that cross build it is more a necessity imposed
by the configure script than my wish. As I am forced to pass
"LDFLAGS=-Wl,--dynamic-link=/usr/lib32/ld-2.17.so" to configure (if not, the
building won't be able to run any auxiliary 32bit components, such as makedep,
unless I statically build them), configure demands the use of host, and then of
--with-wine-tools
--
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=47000
Bug ID: 47000
Summary: Make WineHQ available as flatpak in Flathub
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: yousifjkadom(a)yahoo.com
CC: michael(a)fds-team.de, sebastian(a)fds-team.de
Distribution: ---
Hi.
I would like, here, to suggest to make WineHQ available as flatpak in Flathub.
This will be very useful since flatpak is secure & sandboxed, so user will be a
way from infect heir/his PC by a virus or spywar. If flatpak Wine run a virus,
then it will be like if Wine sandboxed by firejail run such virus.
Moreover, flatpak can minimize time & efforts in packaging because it is a
generic package working in many Linux distro regardless OS version.
Also, Wine contain huge number of 32 bit packages that are, mostly, not needed
by any other application.
--
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=54674
Bug ID: 54674
Summary: Add Flatpak to Download page
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: peter.eszlari(a)gmail.com
Distribution: ---
Since February 2022 Wine has been available as a Flatpak.
To try it:
0. ($ apt install flatpak)
1. $ flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
2. $ flatpak install org.winehq.Wine
3. $ flatpak run org.winehq.Wine prog.exe
build manifest source: https://github.com/flathub/org.winehq.Wine
I think it would make sense to add this to list of binary packages on:
https://wiki.winehq.org/Download
(Note: Wine cannot be found on the Flathub web interface at
https://flathub.org, because only GUI apps are listed there, not CLI apps.)
--
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=37640
Bug ID: 37640
Summary: Opening Windroy and it crashes.
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fholiveira1(a)hotmail.com
Distribution: ---
Created attachment 50094
--> https://bugs.winehq.org/attachment.cgi?id=50094
Extract from Wine report of bug.
I was trying to open Windroy and it crashes. The system open a bug report,
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=54508
Bug ID: 54508
Summary: psapi:psapi_main - The 64-bit
test_EnumProcessModulesEx() gets unexpected snapshot
counts on Windows 7 and 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: psapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets unexpected
snapshot counts on Windows 7 and 11:
w7pro64:
psapi_main.c:483: Test failed: pcs-6432: Wrong count 23 in C:\Windows\SysWOW64
psapi_main.c:488: Test failed: pcs-6432: Wrong count 2 in C:\Windows\system32
w11pro64:
psapi_main.c:488: Test failed: pcs-6432: Wrong count 0 in C:\Windows\system32
See https://test.winehq.org/data/patterns.html#psapi:psapi_main
These failures don't happen on Windows 8 to Windows 10!
These tests and failures were introduced in the following commit:
commit e38455a2181ab5ce0bf842f2c9a638b3ee9b538c
Author: Eric Pouech <eric.pouech(a)gmail.com>
AuthorDate: Tue Feb 14 11:06:57 2023 +0100
psapi/tests: Test directory of enumerated loaded modules.
Showing that Wine incorrectly reports, for a Wow64 process, the system
DLLs from within the wow64 directory while they should be from system32.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
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.