wine-bugs September 2023

1 participants
1632 discussions

[Bug 23124] New: Philippine English locale defaults to wrong SUBLANG

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=23124 Summary: Philippine English locale defaults to wrong SUBLANG Product: Wine Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: download, source Severity: trivial Priority: P4 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk I understand that following 1.2 .po file are going to be used, so this should be easier to resolve then. Philippine English follows American English rules, but currently defaults to pick up SUBLANG_NEUTRAL which is British English. It should be picking up SUBLANG_DEFAULT for American English. I'm not sure if this can be changed before the introduction of .po files but it's not urgent. http://en.wikipedia.org/wiki/Philippine_English -- 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.

3 days, 8 hours

[Bug 44863] New: Performance regression in Prince of Persia 3D

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44863 Bug ID: 44863 Summary: Performance regression in Prince of Persia 3D Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: stefan(a)codeweavers.com Distribution: --- Prince of Persia 3D's performance went from perfectly smooth to about 0.5 fps. I suspect 0b92a6fba7a6e60c6ff1a3729a3b21019c2df0ce is to blame, but I have not run a regression test yet. The problem is that the game creates a rather large (2MB) D3DVBCAPS_SYSTEMMEMORY, maps it (the entire buffer due to API limitations), writes a handful of vertices and draws a handful of vertices. Currently wined3d uploads the entire 2MB, evicts the sysmem copy and downloads it from the GPU every map / unmap / draw cycle. The most obvious performance fix is not to create a VBO. Doing this restores the performance, but questions remain. On startup, the game writes "NetImmerse D3DDriver Info: Hardware supports system memory textures" and "NetImmerse D3DDriver Info: No AGP support detected". The first info seems wrong, so it is possible that the game enters a codepath it does not choose on Windows. Not creating a VBO is not an option on Core Contexts, so I investigated what's going wrong with the PBO codepath on. First of all, evicting the sysmem copy seems like a bad choice. It happens because ddraw buffers are not marked dynamic. We may want to chance this. The game uses d3d3, so there's no DDLOCK_DISCARDCONTENTS. The game passes DDLOCK_WAIT | DDLOCK_WRITEONLY to IDirect3DVertexBuffer::Lock. Commenting out the eviction call improves performance quite a bit, but it is still noticeably slow. wined3d_buffer_map maps through heap_memory instead of glMapBuffer because of the "(flags & WINED3D_MAP_WRITE) && !(flags & (WINED3D_MAP_NOOVERWRITE | WINED3D_MAP_DISCARD))" condition. Removing this condition uses glMapBuffer, but does not improve performance. It seems the large glMapBuffer is still slow, at least on OSX with legacy contexts. So there are a few questions that need to be answered: *) Is the game using a broken codepath? *) Write tests for sysmem buffers *) Consider making all d3d3 buffers dynamic *) Test if the glMapBuffer path is fast on Linux *) Investigate if Core Contexts + GL_ARB_buffer_storage help on OSX. -- 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.

3 days, 13 hours

[Bug 54270] New: Random crashing in Overwatch 2

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54270 Bug ID: 54270 Summary: Random crashing in Overwatch 2 Product: Wine Version: 8.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: nanotwerp(a)gmail.com Distribution: --- While playing Overwatch 2, I experience random crashing. This especially happens when I play Ashe, and I do not recall it happening while playing other characters, but this could be a coincidence. The error I get is: free(): invalid pointer 06a8:err:seh:call_stack_handlers invalid frame 0000000027B4E3E0 (0000000027952000-0000000027A50000) 06a8:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. The same issue was also noted by someone who posted this Blizzard bug report: https://us.forums.blizzard.com/en/blizzard/t/random-crashes-in-game-wow-cla… I believe that this issue is what this merge request by Torge Matthies was made to fix: https://gitlab.winehq.org/wine/wine/-/merge_requests/1152 . Oddly enough, though, after applying Matthies' patch rebased to 8.0-rc2 (https://github.com/openglfreak/wine-tkg-userpatches/search?q=overwatch), I still experience this error. I think that some change in 8.0 (Full-ish PE conversion maybe?) caused this incompatibility with Overwatch 2. -- 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.

4 days, 9 hours

[Bug 55545] New: Rustup cannot download information related to toolchains

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55545 Bug ID: 55545 Summary: Rustup cannot download information related to toolchains Product: Wine Version: 8.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lorenzofer(a)live.it Distribution: ArchLinux Created attachment 75105 --> https://bugs.winehq.org/attachment.cgi?id=75105 WINEDEBUG=+secur32,+winsock,+wininet,+crpyt log Hi. Try to install a Rust toolchain using rustup fails with error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml' to 'C:\users\lorenzo\.rustup\tmp\wfcpd9ms_ve5wz19_file.toml': error decoding response body: operation timed out: operation timed out Used: https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init… The 32bit (i686) version advance a bit further, but fails to download the tolchain Attaching a WINEDEBUG=+secur32,+winsock,+wininet,+crpyt log -- 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.

4 days, 21 hours

[Bug 53799] New: FFXIV Endwalker Benchmark no audio and crashes in xaudio2_7 on exit

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53799 Bug ID: 53799 Summary: FFXIV Endwalker Benchmark no audio and crashes in xaudio2_7 on exit Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: nospam(a)kota.moe Distribution: --- Created attachment 73297 --> https://bugs.winehq.org/attachment.cgi?id=73297 Console output (including crash info) The application in question can be downloaded from https://jp.finalfantasyxiv.com/benchmark/download/ (Direct link: https://download.finalfantasyxiv.com/ys8glaimvmykn88p/ffxiv-endwalker-bench…) It can be executed with the following command line (not enough arguments to fully configure the benchmark, but enough to demonstrate the problem): wine game/ffxiv_dx11.exe SYS.Language=1 When the application is running, no audio is heard when there should be audio. And when it exits (such as closing the window, pressing ESC, or letting it finish), it will segfault in xaudio2_7 with the following backtrace (full output in attachment): =>0 0x00000242e0aeac FAudio_AudioClientThread+0xcc(user=00000000010301B0) [Z:\tmp\wine-src\libs\faudio\src\FAudio_platform_win32.c:190] in xaudio2_7 (0000000000000000) 1 0x0000007b629109 BaseThreadInitThunk+0x9(unknown=<internal error>, entry=<internal error>, arg=<internal error>) [Z:\tmp\wine-src\dlls\kernel32\thread.c:61] in kernel32 (0000000000000000) 2 0x0000017005eda3 __wine_pop_frame(entry=0000000242E0ADE0, arg=00000000010301B0) [Z:\tmp\wine-src\include\wine\exception.h:277] in ntdll (0000000000000000) 3 0x0000017005eda3 RtlUserThreadStart+0x83(entry=[<register RSP not accessible in this frame>, arg=[<register RSP not accessible in this frame>) [Z:\tmp\wine-src\dlls\ntdll\thread.c:240] in ntdll (0000000000000000) 0x00000242e0aeac FAudio_AudioClientThread+0xcc [Z:\tmp\wine-src\libs\faudio\src\FAudio_platform_win32.c:190] in xaudio2_7: movq (%rcx),%rax 190 FAudio_assert(!FAILED(hr) && "Failed to stop IAudioClient!"); This was run in a clean WINEPREFIX with wine-7.19 freshly built from source. If I use winetricks to install xact_x64, the crash goes away, but there is still no audio output -- 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.

4 days, 22 hours

[Bug 44315] New: Guild Wars 2 - Slow Performance since Wine 2.1

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44315 Bug ID: 44315 Summary: Guild Wars 2 - Slow Performance since Wine 2.1 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jonfarr87(a)gmail.com Distribution: Mint Created attachment 60162 --> https://bugs.winehq.org/attachment.cgi?id=60162 Screenshot showing performance between old and newer Wine versions. Wine 2.0 (with Staging patches) was the last version to run this game at a good performance, From 2.1 up to 3.0rc5 it results in a major framerate loss in every aspect of the game. The staging versions (up to 2.21) perform the same as "non staging" Wine. While no other of my tested games were affected, it looks as if something in CSMT was changed and affected this particular title. I've tested this across multiple system configurations and the results are always the same. Considering how much this game struggles to maintain a playable framerate, a loss of 15-25 frames (depending on the situation) is a bit excessive. Screenshot attached, showing the frames difference in an instanced area of game where the performance can easily be used as a "benchmark". Tests have been performed on 3 systems: Ryzen 1700X 16GB DDR4 2800MHZ Ram Nvidia GTX 1060 / v384.98 Drivers ------------------------------------------- i5-4590 8GB DDR3 Ram Nvidia GTX 960 / 384.98 Drivers ------------------------------------------- i5-2400 8GB DDR3 Ram Nvidia GTX 760 / 375.66 Drivers -- 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.

4 days, 22 hours

[Bug 43280] New: Gothic 1, no Music

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43280 Bug ID: 43280 Summary: Gothic 1, no Music Product: Wine-staging Version: 2.10 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shitman71(a)hotmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Music not working in Gothic 1 and other games, this was introduced with windows vista sp1. They did some changes to their soundsystem or something like this, this affected many games. I gues this was introduced in wine too. I dont know what exactly was done but i know problems with music existed even in win8.1. -- 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.

5 days, 2 hours

[Bug 26407] New: Shadowgrounds Survivor crashes after viewing the map

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=26407 Summary: Shadowgrounds Survivor crashes after viewing the map Product: Wine Version: 1.3.15 Platform: x86 URL: http://www.gamershell.com/download_23192.shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com Created an attachment (id=33629) --> (http://bugs.winehq.org/attachment.cgi?id=33629) terminal output In the game the crash always occurs when I switch back to normal mode after viewing the map (by pressing <Tab>). Sometimes the game "survives" 2-3 switches between the two modes but eventually it will crash. How to reproduce the problem in the demo: 1. Choose only Physx and Windows Media Codecs when the installer asks for it (native d3dx9_36.dll will be placed in the game directory). 2. Start the game either by survivor.exe or with the launcher. 3. Choose <New Game> from the menu. When you gain control over your character press <Tab> to switch to map mode then press <Tab> again to get back to normal mode. This might need to be repeated 2-3 times. Sooner or later the game will crash. If I don't use the map mode, the game seems to be stable (I've played for about 30-40 minutes). I can reproduce the crash with Wine-1.0.1, too. The crash happens even if I lower the gfx details to the minimum and with disabled audio. When starting the game with WINEDEBUG=warn+heap (is that the correct syntax?) the crash doesn't occur. Fedora 14 x86 Nvidia GeForce 250 / driver 260.19.36 -- 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.

5 days, 3 hours

[Bug 55334] New: Steam fails to load if compiled --with-wine64

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55334 Bug ID: 55334 Summary: Steam fails to load if compiled --with-wine64 Product: Wine Version: 8.13 Hardware: x86-64 URL: https://cdn.cloudflare.steamstatic.com/client/installe r/SteamSetup.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: imwellcushtymelike(a)gmail.com Distribution: Ubuntu Created attachment 74927 --> https://bugs.winehq.org/attachment.cgi?id=74927 wine-8.13 console output (eventually killed with SIGHUP) Steam fails to load if compiled with --with-wine64. Sometimes it'll let you know something has crashed and give you options to restart various components (including the whole thing) but it makes no difference. A. This does not occur if Wine is compiled with --enable-archs=x86_64,i386. B. It also does not occur using the official Wine binaries (for Ubuntu). I have tried finding a library and/or kernel issue, but I cannot find it. The openSUSE logs don't seem to build with --with-wine64. I don't know how those binaries actually work. Something to do with multiarch setup? I've tried building with a number of Ubuntu versions, Debian Stable and Testing, and openSUSE Tumbleweed but the result is always the same. My build process: CFLAGS="-g -O0 -pipe" 64 bit: configure --enable-win64 => wine64 32 bit (schroot): configure => wine32 Combine (schroot): configure --with-wine64=wine64 --with-wine-tools=wine32 i386 chroots are need to build 32-bit Wine parts. $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0 Also tried GCC 12 but no change. Tried compiling a few older Wines but it made no difference, and eventually hit other bugs. Doesn't look like a regression. From what I can see in htop it looks like one of the steamwebhelper processes is the problem, but I don't know what the problem is exactly. My guess is there's a problem with the i386 part (or some sort of chroot madness?). (A) and (B) don't seem to touch 32-bit libraries, at least not in the same way. I'm at a loss. Waffle: https://forum.winehq.org/viewtopic.php?t=37852 Note: On first run Steam will self-update. This seems to work fine. No log-in needed to get this far. -- 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.

5 days, 6 hours

[Bug 51139] New: Application T@X 2021 freezes when trying to transmit data to Elster (German Tax Application)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51139 Bug ID: 51139 Summary: Application T@X 2021 freezes when trying to transmit data to Elster (German Tax Application) Product: Wine Version: 6.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dieter.jurzitza(a)harman.com Distribution: --- T@X20XX can be used with wine since years. This year it apparently worked as usual, with one frustrating exception: when trying to transfer the entire documetation to the finance office at the end the application freezes and does noting any more. Unfortunately no error shows in the logs when starting wine with a corresponding debug option (WINEDEBUG=+relay, I hope this is ok ...). I have 32 GByte of logging code what is meaningless to upload - but no "real" error message inside. "top" shows 100% CPU - load by the wine process stman.exe. Messages show like: 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6 01b8:Ret ntdll.RtlAllocateHeap() retval=3ec3bbe0 ret=089a10d6 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6 01b8:Ret ntdll.RtlAllocateHeap() retval=2f24da98 ret=089a10d6 01b8:Call KERNEL32.HeapFree(00220000,00000000,2f24da98) ret=0899e7eb 01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb 01b8:Call KERNEL32.HeapFree(00220000,00000000,3ec3bbe0) ret=0899e7eb 01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb in fast sequence and this: 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000014) ret=6be509ba 01b8:Ret ntdll.RtlAllocateHeap() retval=31991020 ret=6be509ba 0238:Call ntdll._strnicmp(17f9c7cc "Inter-| Receive | Transmit\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000008,00000014) ret=6be7960b 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31983590 ret=6be7960b 0238:Call ntdll._strnicmp(17f9c7cd "face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000020) ret=6be798c1 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31992478 ret=6be798c1 0238:Call ntdll._strnicmp(17f9c7d0 "lo: 376975 3786 0 0 0 0 0 0 376975 3786 0 0 0 0 0 0\n",17f9ca0c "eth1",00000004) ret=7eceaa21 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,0000000c) ret=6be7974e 0238:Call ntdll._strnicmp(17f9c7ce "eth1: 727671935 574392 0 0 0 0 0 2870 31275660 279019 0 0 0 0 0 0\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31991978 ret=6be7974e 0238:Ret ntdll._strnicmp() retval=00000000 ret=7eceaa21 cycling through eth0, eth1, wlan0 etc ... Finally I see once this at the begin (when the trouble starts ...): 01b8:Ret ntdll.RtlAllocateHeap() retval=3ecc7cc8 ret=089a10d6 01b8:Call KERNEL32.OutputDebugStringW(3ecc7cd8 L"void __thiscall BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=67020427 01b8:Call ntdll.RtlInitUnicodeString(0021d000,3ecc7cd8 L"void __thiscall BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=7b0125fa 01b8:Ret ntdll.RtlInitUnicodeString() retval=00000082 ret=7b0125fa with the "void __thiscall entries - but no clue on my behalf. Any support is very much appreciated, most specifically what could I do and how could I better debug the process without flooding my harddisk with trillions (ok, maybe less :-)) of messages. Thank you very much, take care Dieter Jurzitza -- 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.

5 days, 7 hours

← Newer
1
2
3
4
5
6
7
...
164
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs September 2023