wine-bugs

wine-bugs@winehq.org

1 participants
158775 discussions

[Bug 54161] New: quartz:filtergraph sometimes times out in Wine
by WineHQ Bugzilla 16 Dec '22

16 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54161 Bug ID: 54161 Summary: quartz:filtergraph sometimes times out in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- quartz:filtergraph sometimes times out in Wine. In MR!1820 the timeout happened on exit (debian11-win32): ... filtergraph.c:5567: Test marked todo: Got param2 0xdeadbeef. 0d70:filtergraph: 7291 tests executed (81 marked as todo, 0 as flaky, 0 failures), 0 skipped. quartz:filtergraph:0d70 done (258) in 120s 5680B In the nightly WineTest runs filtergraph timeouts only happen on my desktop and my Debian 11 VM; maybe because they usually see more other CPU activity. See https://test.winehq.org/data/patterns.html#quartz:filtergraph The nightly results show only 7 instances in 6 months where filtergraph timed out on exit as above (e.g. 2022-09-27 fgtb-debian1-wow32). It is a lot more common for it to timeout on startup: 17 instances over 6 months. For instance on 2022-11-22 fgtb-debian11-wow32: filtergraph.c:616: running L"test.avi" quartz:filtergraph:0424 done (258) in 120s 40B Given that filtergraph normally runs in about 10 seconds it seems unlikely that this is just a case of the test running a little bit too slow. -- 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 1

[Bug 54152] New: mshtml:misc sometimes times out in Wine
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54152 Bug ID: 54152 Summary: mshtml:misc sometimes times out in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- mshtml:misc sometimes times out on exit in Wine. Sometimes the timeout happens on exit: 0a50:misc: 244 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. mshtml:misc:0a50 done (258) in 120s 86B and sometimes before in which case there is no trace: mshtml:misc:04c0 done (258) in 120s 0B See https://test.winehq.org/data/patterns.html#mshtml:misc The first timeout happened on 2022-11-10 but there is only a bit over 1 per month. Also the GitLab CI seems to be more prone to getting those. There is also one case where the test got a failure instead: misc.c:257: Test failed: key failed 80004005 0a4c:misc: 244 tests executed (0 marked as todo, 0 as flaky, 1 failure), 0 skipped. mshtml:misc:0a4c done (1) in 0s 131B 256 hres = IHTMLStorage_key(storage, -1, &key); 257 ok(hres == E_INVALIDARG, "key failed %08lx\n", hres); Where: 0x80004005 == E_FAIL 0x80070057 == E_INVALIDARG Hopefully that failure is related and the timeout is caused by either HTMLStorage_key() going into an infinite loop or corrupting the memory. -- 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 54047] New: wiaservc:wia sometimes crashes on Windows 11
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54047 Bug ID: 54047 Summary: wiaservc:wia sometimes crashes on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wia Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wiaservc:wia sometimes crashes on Windows 11: 0d78:wia: unhandled exception c0000005 at 00007FFE62E43777 See https://test.winehq.org/data/patterns.html#wiaservc:wia This failure is pretty rare and since there is no trace or backtrace whatsoever it's unclear where the crash occurs. Note: On Windows 10 21H1+ it times out instead of crashing (see bug 54046). These two issues may well be related (memory corruption?). -- 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 54154] New: winmm:midi sometimes crashes on exit in Wine
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54154 Bug ID: 54154 Summary: winmm:midi sometimes crashes on exit in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- winmm:midi sometimes crashes on exit in Wine: 0494:midi: 445 tests executed (4 marked as todo, 0 as flaky, 0 failures), 0 skipped. winmm:midi:0494 done (-1073741819) in 7s 5788B See https://test.winehq.org/data/patterns.html#winmm:midi Where -1073741819 == 0xc0000005 The pid of the test summary line matches the one printed by the WineTest executable which means this is the summary line of the main process. That means the crash happens on exit, probably as the result of memory / stack corruption. There have been 24 crashes in the past 6 months but they became more frequent after the 2022-09-16 which may correspond to the TestBot switching to running two VMs are a time. So the failure may be caused by extra load. There is also at least one case of a timeout on exit (2022-12-09 on debian11-win32-ja-JP), which is probably the same issue: 05fc:midi: 445 tests executed (4 marked as todo, 0 as flaky, 0 failures), 0 skipped. winmm:midi:05fc done (258) in 120s 5788B -- 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 1

[Bug 54153] New: kernel32:debugger - test_kill_on_exit() sometimes gets STILL_ACTIVE exit code on Windows
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54153 Bug ID: 54153 Summary: kernel32:debugger - test_kill_on_exit() sometimes gets STILL_ACTIVE exit code on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com kernel32:debugger - test_kill_on_exit() sometimes gets STILL_ACTIVE exit code on Windows: debugger.c:2078: Test failed: exit code = 00000103 See https://test.winehq.org/data/patterns.html#kernel32:debugger Where 0x103 == STILL_ACTIVE == STATUS_PENDING This should mean the process is still running. So either there is a race condition in the test or Windows 8 and 10 21H1 are buggy. With only 3 instances in 6 months this failure is pretty rare: * 2022-07-11 on w10pro64-ar (64-bit, 21H1) * 2022-10-31 on w864 (64-bit) * 2022-12-06 on w864 (64-bit) -- 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 1

[Bug 54107] New: Windows Defender interferes with the tests on w1064v1909
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54107 Bug ID: 54107 Summary: Windows Defender interferes with the tests on w1064v1909 Product: Wine-Testbot 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 Windows Defender interferes with the tests on w1064v1909: sc.exe:sc start programs/sc/tests/sc.c sc.exe:sc:0000 done (-225) in 0s 0B Where 225 == ERROR_VIRUS_INFECTED This is because in this snapshot was created before Windows Defender became a problem and thus has no exclusion for the folder where the TestBot puts the test binaries. w1064v2009 (and presumably snapshots of newer Windows versions) has the needed exclusion. v1064v1809 (and presumably snapshots of older Windows versions) does not have an exclusion but has "Real-time protection" turned off which should ensure Defender won't interfere (that option is not available in newer Windows (Defender) 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 4

[Bug 54128] New: user32:msg - test_PeekMessage3() sometimes gets an unexpected WM_TIMECHANGE message on Windows 10
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54128 Bug ID: 54128 Summary: user32:msg - test_PeekMessage3() sometimes gets an unexpected WM_TIMECHANGE message on Windows 10 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com test_PeekMessage3() sometimes gets an unexpected WM_TIMECHANGE message on Windows 10: msg.c:13549: Test failed: msg.message = 30 instead of WM_TIMER msg.c:13552: Test failed: msg.message = 275 instead of WM_USER + 1 msg.c:13554: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:13564: Test failed: msg.message = 1025 instead of WM_TIMER msg.c:13566: Test failed: msg.message = 275 instead of WM_USER msg.c:13568: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:13577: Test failed: msg.message = 1024 instead of WM_TIMER msg.c:13579: Test failed: expected PeekMessage to return FALSE, got 1 See https://test.winehq.org/data/patterns.html#user32:msg Where 30 == WM_TIMECHANGE 275 == WM_TIMER 1024 == WM_USER 1025 == WM_USER + 1 This is similar to the issue happening in test_PeekMessage2() in bug 53273. This last happened on 2022-12-09 on w10pro64-pt-BR where the Internet time synchronization has not been disabled. So that may be the source of the WM_TIMECHANGE messages. The TestBot now has code to disable Internet time synchronization but the snapshots have not all been updated. So this bug should be revisited once they have been updated to see if the failures are still happening. -- 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 1

[Bug 54076] New: windows.globalization:globalization - test_GlobalizationPreferences() sometimes unexpectedly returns en_US on Windows 10
by WineHQ Bugzilla 15 Dec '22

15 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54076 Bug ID: 54076 Summary: windows.globalization:globalization - test_GlobalizationPreferences() sometimes unexpectedly returns en_US on Windows 10 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 windows.globalization:globalization - test_GlobalizationPreferences() sometimes unexpectedly returns en_US on Windows 10: globalization.c:137: Test failed: IGlobalizationPreferencesStatics_get_Languages 0 returned len 5, str L"en-US", expected L"de-DE" globalization.c:177: Test failed: IGlobalizationPreferencesStatics_get_Languages 0 returned len 5, str L"en-US", expected L"de-DE" See https://test.winehq.org/data/patterns.html#ws2_32:sock This failure first happened on 2022-11-22 and impacts the de, fr, ja, ko, pt-BR and ru locales of the w10pro64 VM. It's not systematic but is frequent enough that it seems like it does not impact the other locales. The timing of the first failure is suspicious: * The w10pro64 had a problem where Windows 10 would reset UserDefaultLCID, ThreadLocale and Country to en_US when the TestBot called SetSystemTime() to update the clock in the live snapshot. As long as this issue was there there was no failure. * On 2022-11-21 LibvirtTool got a workaround to re-set these locale settings after setting the time and the failures started. So this sounds like Windows is still messing with the locales :-( -- 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 54147] New: Kholat from GOG: Splash video are not in fullscreen
by WineHQ Bugzilla 14 Dec '22

14 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=54147 Bug ID: 54147 Summary: Kholat from GOG: Splash video are not in fullscreen Product: Wine Version: 8.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: titan.costa(a)gmail.com Distribution: --- Wine wine-8.0-rc1. Ubuntu 22.10. From bug https://bugs.winehq.org/show_bug.cgi?id=50043. -- 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 1

[Bug 52930] New: d3dcompiler_47:hlsl_d3d9 fails randomly on Windows
by WineHQ Bugzilla 14 Dec '22

14 Dec '22

https://bugs.winehq.org/show_bug.cgi?id=52930 Bug ID: 52930 Summary: d3dcompiler_47:hlsl_d3d9 fails randomly on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d-util Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 72305 --> https://bugs.winehq.org/attachment.cgi?id=72305 Small patch to apply on top of 58d20aae3772^ to get failures d3dcompiler_47:hlsl_d3d9 fails randomly on Windows 8.1 to 21H2: hlsl_d3d9.c:1691: Test failed: Got unexpected hr 0x88760b59. hlsl_d3d9.c:1692: Test failed: Got unexpected blob. hlsl_d3d9.c:1693: Test failed: Got unexpected errors. https://test.winehq.org/data/patterns.html#d3dcompiler_47:hlsl_d3d9 A bisect against Windows 10 21H1 on cw-gtx560 shows that the failures started with the commit below: commit 58d20aae3772473a90e43ee236b793f0421eecb1 Author: Eric Pouech <eric.pouech(a)gmail.com> Date: Tue Feb 8 19:48:44 2022 +0100 d3dcompiler/tests: Build without -DWINE_NO_LONG_TYPES. Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> The patch does not actually make any change that should matter but I have confirmed the bisect result manually: 58d20aae3772^ -> 200 consecutive runs with no failure 58d20aae3772 -> fails after 9 to 33 runs - Applying just the Makefile.in parts and last 4 chunks of hlsl_d3d9.c of that commit is sufficient to get the failures. - Patching only the makefiles is not enough. - I did not try to identify which of the 4 chunks are needed to get failures. They all patch code that's executed after the failure anyway. So there must be some memory corruption that's sensitive to memory layout or some subtle issue with the generated code. I also if(0)ed-out all the other test_xxx() functions, and also if(0)ed-out the tests that preceded the failing one in test_include() but I still get the failure so it's not a case where an ill-advised NULL-behavior test causes memory corruption. -- 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:

2025

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