wine-bugs April 2022

wine-bugs@winehq.org

1 participants
3449 discussions

[Bug 52847] New: GetACP() returns CP_UTF8 on some debian VM
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52847 Bug ID: 52847 Summary: GetACP() returns CP_UTF8 on some debian VM Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: eric.pouech(a)orange.fr Distribution: --- wine's tests in kernel32/tests/process.c fail on some Debian VM (Dhivehi:Maldives and Hindi:India) debugging it shows: - conhost (in window.c) aborts at startup because TranslateCharsetInfo( GetACP() ...) fails in Wine - both locale return CP_UTF8 from GetACP() - testing on windows vm (Hindi), show that GetACP() returns 1252 CP - moreover, testing on Win11 TranslateCharsetInfo( CP_UTF8 ) succeeds returning the Win11 values for CP_UTF8 in TranslateCharsetInfo let the kernel32:process run "correctly" (ie no longer showing the specific errors related to TranslateCharsetInfo) -- 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.

1 2

[Bug 48045] New: comdlg32:filedlg crashes or times out randomly
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=48045 Bug ID: 48045 Summary: comdlg32:filedlg crashes or times out randomly Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: comdlg32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 65586 --> https://bugs.winehq.org/attachment.cgi?id=65586 comdlg32:filedlg: Traces to debug random crash / timeouts. comdlg32:filedlg crashes randomly on all Windows versions from Vista to Windows 8 while Windows 10 (at least 1507, 1709 and 1809) gets random timeouts. https://test.winehq.org/data/tests/comdlg32:filedlg.html When successful comdlg32:filedlg does not print much so the standard reports are pretty much useless to spot the place where the test gets stuck on Windows 10, assuming it gets stuck in a specific place rather than just being slow. As for the crashes, they don't trigger the tests exc_filter() so there is no indication of the last successful ok() call. Turning on 'Report successful tests' may be preventing the crash (or these runs just got lucky). It's possible to reproduce the crash while adding the traces in the attached patch. This is not entirely fruitful as the crashes don't seem to always happen in the same place. test_extension() is the place where most issues happen though: https://testbot.winehq.org/JobDetails.pl?Key=59060 -> wvistau64: Crash in test_extension(). Based on the test_extension_helper() traces, it happened in the loop with i=1 so for "TestFilter (*.abc;)\0*.abc;\0". https://testbot.winehq.org/JobDetails.pl?Key=59086 -> w2008s64+exe: Crash on or after test_extension() return https://testbot.winehq.org/JobDetails.pl?Key=59088 -> wvistau64+exe: Crash in test_DialogCancel() https://testbot.winehq.org/JobDetails.pl?Key=59091 -> wvistau64_fr: Spent 39s in test_null_filename() but no timeout https://testbot.winehq.org/JobDetails.pl?Key=59139 -> wvistau64: Crash in test_null_filename() -> wvistau64_fr: Timeout in test_extension() filedlg.c:1048: filter=[TestFilter (*.ab?) lpstrDefExt=NULL] https://testbot.winehq.org/JobDetails.pl?Key=59151 -> wvistau64: Crash in test_extension() filedlg.c:1048: filter=[TestFilter (*.abc.def)] -> wvistau64_fr: Timeout in or after test_mru() filedlg.c:637: 19 test_ok filedlg.c:904: 29 test_getfolderpath filedlg.c:986: 30 test_mru -> w1064v1809_zh_CN: Two failures in test_extension() filedlg.c:1053: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1059: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xyz Memory corruption, maybe happening quite early in the test? -- 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.

1 3

[Bug 52924] New: Guilty Gear XX #Reload: black screen since wine 5.0
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52924 Bug ID: 52924 Summary: Guilty Gear XX #Reload: black screen since wine 5.0 Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: s.guidoni(a)tin.it Distribution: --- Since wine 5.0 the game "Guilty Gear XX ♯Reload" shows a black screen while running. The game starts, the introductory videos are displayed correctly, then the game runs, but the screen is just black, with some blocky piece of graphics flashing now and then across the screen. The sound plays, so one can browse the menu, start a game and so on, but the screen stays black with some bright rectangular shape flashing around. The game is based on DirectX 8.1 and the last wine version that works is 4.21. With wine 4.21, the console output is: 002d:fixme:win:EnumDisplayDevicesW ((null),0,0x33f798,0x00000000), stub! 002f:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. 002d:err:quartz:GetClassMediaFile Media class not found 002d:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. With wine 5.0.5, it is: 0033:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 0033:fixme:d3d:wined3d_swapchain_init Unimplemented swap effect 0x5. 0035:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. 0033:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. With wine 7.6, it is: 012c:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0x3. 012c:err:winediag:wined3d_dll_init Using the OpenGL renderer. 012c:fixme:imm:ImeSetActiveContext (0x266c88, 1): stub 012c:fixme:imm:ImmReleaseContext (0002010C, 00266C88): stub 012c:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command streams. 012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command streams. 012c:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. -- 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.

1 7

[Bug 52871] New: oleaut32:vartest has failures in Wine in the Arabic and Hebrew locales
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52871 Bug ID: 52871 Summary: oleaut32:vartest has failures in Wine in the Arabic and Hebrew locales Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- oleaut32:vartest has failures in Wine in the Arabic and Hebrew locales: vartest.c:3130: Test failed: VarAbs: expected 0x0,5,1.1, got 0x80020005,8,-1.#IND vartest.c:4073: Test failed: wrong result 80020005 vartest.c:4188: Test failed: wrong result 80020005 vartest.c:4312: Test failed: wrong result 80020005 vartest.c:4444: Test failed: wrong result 80020005 vartest.c:7785: Test failed: VarCmp: 2|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 3|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 4|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 5|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 6|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 7|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 2|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 3|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 4|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 5|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 6|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 7|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 11|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 14|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 17|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 8|0x8000, 20|0x8000: Expected 0x0, got 0x2 vartest.c:7785: Test failed: VarCmp: 11|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 14|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 17|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 20|0x8000, 8|0x8000: Expected 0x2, got 0x0 vartest.c:7785: Test failed: VarCmp: 22|0x8000, 8|0x8000: Expected 0x2, got 0x0 https://test.winehq.org/data/patterns.html#oleaut32:vartest These failures happen in test_VarAbs(), test_VarFix(), test_VarInt(), test_VarNeg(), test_VarRound() and test_VarCmp() but a bisect shows that they all start with this commit: commit ba43e4cfca97a9bba3e6575af82acbf011685862 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Mar 29 22:11:32 2022 +0200 kernelbase: Reimplement number formatting values in GetLocaleInfoW/Ex using the locale.nls data. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> It should be noted that this commit did fix another set of oleaut32:vartest failures (which were likely introduced by 2cd33e6b0fd6). -- 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.

1 4

[Bug 52865] New: windows.media.speech:speech has a Windows 10 1507-specific failure
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52865 Bug ID: 52865 Summary: windows.media.speech:speech has a Windows 10 1507-specific failure Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com IAsyncOperation_SpeechRecognitionCompilationResult_get_Completed() unexpectedly returns a handle on Windows 10 1507: speech.c:979: Test failed: Handler had value 0029FC20. https://test.winehq.org/data/patterns.html#windows.media.speech:speech Unsurprisingly a bisect shows that the failures started with the commit that introduced this new test: commit 4926bb148b049f1b60e57091f4aa87a3957aa69e Author: Bernhard Kölbl <besentv(a)gmail.com> Date: Wed Apr 6 18:28:41 2022 +0200 windows.media.speech: Add tests for IAsyncOperation. Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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.

1 3

[Bug 52845] New: Recent versions of chromium have broken sandbox again
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52845 Bug ID: 52845 Summary: Recent versions of chromium have broken sandbox again Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Somewhere between chromium-946247 (commit 4e7609b62147866fb7b226fd6efbe1ae4d2f1aca and chromium-946263 (commit 1bd694702105072e57b980512130a3212675ec19) the sandbox got changes so it doesn't work under wine anymore. Result is a black screen and soon a crash. This affects both 32bit and 64bit chromium. Note: chromium should be located inside the WINEPREFIX, it won't run outside! Nightly versions to test with (chrome-win.zip) https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h… https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h… I tried to build from source on my Win11 machine, but those versions don't run under wine at all, even if compiling the same commit as the nightly versions. -- 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.

1 9

[Bug 52554] New: Serbian locale mapping cause crash on multiple installshield wizards
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52554 Bug ID: 52554 Summary: Serbian locale mapping cause crash on multiple installshield wizards Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: lei.pero(a)gmail.com Distribution: --- Since commits: kernelbase: Map LANG_SERBIAN_NEUTRAL in ConvertDefaultLocale(). f51e44c1802338cdd41b38efe2757b642b619d6f ntdll: Map LANG_SERBIAN_NEUTRAL in RtlLocaleNameToLcid(). db3e08770fe9bfb6f06a71761e48a40fe9764058 starting with wine-6.2 - when using locale sr_RS.UTF-8, some (specifically older) installers do crash, for example 3DMark03, preventing installation, passing LANG=en_US.UTF-8 EV works as expected with no crash. Reverting those two specific commits solves the issue. Or changing line in: dlls/ntdll/locale.c from: case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ): *lcid = LANG_SERBIAN_NEUTRAL; to: case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ): *lcid = MAKELCID( 0x02, SORT_DEFAULT ); solves the issue as well, but that basically renders all those commits useless I assume? On the topic, but unrelated to this bug, I can see changes in dlls/kernel32/nls/srl.nls, with commit: kernel32: Update sr-Latn locale definition. 3b3dfda59951b0f42e297f2b9a31ded04a98d4b4 that doesn't seem right to me, srl.nls should stand for Serbian Latin I assume, srm.nls probably stands for m as Montenegro. So, if I'm correct, addition of srm.nls with commit: kernel32: Add sr-Latn-RS locale definition. db2666e9d20f80968ff6b4b0ea1deae20c3c368b should have changes made to srl.lns. I don't know how this is solved for English for example, since neutral should have a specific code not related to any country where language is used (e.g. US, UK, CA etc.), and the code it seems to be sr_CS as it is changed for sr_RS latin locale, where it shouldn't be changed I assume. -- 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.

1 8

[Bug 51181] New: d3d10core:d3d10core fails systematically on AMD GPUs
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=51181 Bug ID: 51181 Summary: d3d10core:d3d10core fails systematically on AMD GPUs Product: Wine Version: 6.8 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com test_instanced_draw() fails systematically in d3d10core:d3d10core on AMD GPUs (and sometimes there is a crash that follows): d3d10core.c:9275: Test failed: Got 0xfff0f010, expected 0xff80f010 at (160, 0), sub-resource 0. d3d10core.c:9275: Test failed: Got 0xfff0f040, expected 0xff80f040 at (240, 0), sub-resource 0. d3d10core.c:9275: Test failed: Got 0xffaaaacc, expected 0xffbbaacc at (480, 0), sub-resource 0. d3d10core.c:9275: Test failed: Got 0xffaaaa90, expected 0xffbbaa90 at (560, 0), sub-resource 0. Notice how this failure does not happen on the machines that have other GPUs such as cw-gtx560 or QEmu VMs, and how this does not depend on the Windows version or Radeon driver version for that matter: https://test.winehq.org/data/patterns.html#d3d10core:d3d10core So it looks like the test expects fails to account for the Radeon driver results for some reason. The commit that introduced this test is: commit fcd549345d96109179b125d31baf9e9073ecf643 Author: Józef Kucia <jkucia(a)codeweavers.com> AuthorDate: Mon Nov 6 10:55:20 2017 +0100 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Mon Nov 6 19:37:09 2017 +0100 d3d10core/tests: Add test for SV_InstanceID. Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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.

1 8

[Bug 43995] New: Uplay - Assassin's Creed 4 Black Flag won't start
by wine-bugs＠winehq.org 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=43995 Bug ID: 43995 Summary: Uplay - Assassin's Creed 4 Black Flag won't start Product: Wine-staging Version: 2.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mi.bar.2001(a)gmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 59652 --> https://bugs.winehq.org/attachment.cgi?id=59652 Terminal log from `wine AC4BFSP.exe` After clicking the "Play" button in Ubisoft Game Launcher (or launching `wine AC4BFSP.exe`), a window pops up informing, that the game is starting, but it disappears and the game doesn't launch. I don't have the Steam version, just the Uplay one. I've set Windows version to XP, wineprefix is 32-bit. Wine version will probably be visible when I post this, but I'm going to mention it just to be safe. Using Wine 2.20 staging -- 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.

2 38

[Bug 52856] New: kernel32:process fails when Wine has no Unix terminal
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52856 Bug ID: 52856 Summary: kernel32:process fails when Wine has no Unix terminal Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- kernel32:console fails on the TestBot Wine machines: process.c:1552: Test failed: Opening ConIn process.c:1553: Test failed: Opening ConOut process.c:1556: Test failed: Getting sb info process.c:1557: Test failed: Getting console in mode process.c:1558: Test failed: Getting console out mode process.c:212: 5 failures in child process process.c:1569: Test failed: Getting sb info process.c:1570: Test failed: Getting console in mode process.c:1571: Test failed: Getting console out mode process.c:1582: Test failed: GetLastError: expecting 87 got 12 process.c:1592: Test failed: GetLastError: expecting 87 got 12 process.c:1621: Test failed: Console:SizeX expected 30870, but got 0 process.c:1622: Test failed: Console:SizeY expected 31489, but got 0 process.c:1623: Test failed: Console:CursorX expected 32644, but got 0 process.c:1624: Test failed: Console:CursorY expected 94, but got 0 process.c:1625: Test failed: Console:Attributes expected 0, but got 1 process.c:1626: Test failed: Console:winLeft expected 0, but got 1 process.c:1627: Test failed: Console:winTop expected 4294964424, but got 0 process.c:1628: Test failed: Console:winRight expected 49, but got 0 process.c:1629: Test failed: Console:winBottom expected 30870, but got 0 process.c:1630: Test failed: Console:maxWinWidth expected 31489, but got 0 process.c:1631: Test failed: Console:maxWinHeight expected 11256, but got 0 process.c:1634: Test failed: Console:InputMode expected 0, but got 1 process.c:1635: Test failed: Console:OutputMode expected 7211040, but got 0 process.c:1639: Test failed: Wrong console CP (expected 1252 got 0/0) process.c:1640: Test failed: Wrong console-SB CP (expected 1252 got 0/0) process.c:1645: Test failed: Wrong console mode process.c:1646: Test failed: Wrong console-SB mode https://test.winehq.org/data/patterns.html#kernel32:process The reason is that the TestBot starts Wine from a daemon process which does not have an associated xterm / Konsole / GNOME terminal. This causes Wine to have to allocate a Wine console and that's when things go wrong. A bisect shows that the TestBot is only impacted by this bug since the commit below: commit eff83cd4e00e8ccd4daad05bdd6d76e77664ddd1 Author: Eric Pouech <eric.pouech(a)gmail.com> Date: Mon Apr 11 15:05:09 2022 +0200 kernelbase: Provide a pseudo console environment for initial CUI processes not tied to a Unix tty. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52771 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52761 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52743 Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> But as the commit entry shows this commit also fixed a lot of other issues in the TestBot results (not least of which is getting the wow64 WineTest results in an acceptable shape for test.winehq.org). Also this issue has happened before as evidenced by bugs 25284 and 28220. However those bugs are very old (~2014) so the issue may have been fixed and reappeared (the TestBot has not used a Unix terminal to run the Wine tests since at least 2018-06 (date on local-testagentd.service) and probably 2017 or more (f1d368722b65 tools commit)). Bug 28220 does have a more recent and interesting comment by Esme with regards to handle inheritance: https://bugs.winehq.org/show_bug.cgi?id=28220#c3 -- 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.

1 5

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 April 2022