[Bug 40191] New: ntdll:rtl test regression
https://bugs.winehq.org/show_bug.cgi?id=40191 Bug ID: 40191 Summary: ntdll:rtl test regression Product: Wine Version: 1.9.3 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The commit below introduced a test failure on Windows 8, 8.1 and 10. Failure: rtl.c:2079: Test failed: expected SpinCount == 0, got 33556432 ntdll:rtl results on test.winehq.org: https://test.winehq.org/data/tests/ntdll:rtl.html commit 2689b7b1be096c8b7755ac3e75d2d366cb3debab Author: Sebastian Lackner <sebastian(a)fds-team.de> Date: Tue Feb 16 08:41:21 2016 +0100 ntdll/tests: Add tests for RtlInitializeCriticalSectionEx. Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> 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.
https://bugs.winehq.org/show_bug.cgi?id=40191 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase URL| |https://test.winehq.org/dat | |a/tests/ntdll:rtl.html Regression SHA1| |2689b7b1be096c8b7755ac3e75d | |2d366cb3debab -- 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=40191 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #1 from Sebastian Lackner <sebastian(a)fds-team.de> --- I've sent a patch to fix this issue. I am really wondering though - why are errors like this not visible when doing a manual testbot run / when submitting a patch? -- 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=40191 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- Based on the WineTest results: * It only fails on real hardware and the TestBot only runs it on QEMU VMs. * It fails the same way whether the machine is running Windows 8, 8.1 or 10. * It fails the same way for 32 and 64 bit tests. * In every failing case the the SpinCount value is 33556432 or 0x020007d0. Does this value mean anything? Maybe it's a CPU topology issue: all VMs emulate a dual single-core processor systems while the failures happen on single multi-core processor machines. -- 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=40191 --- Comment #3 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to François Gouget from comment #2)
Based on the WineTest results: * It only fails on real hardware and the TestBot only runs it on QEMU VMs. * It fails the same way whether the machine is running Windows 8, 8.1 or 10. * It fails the same way for 32 and 64 bit tests. * In every failing case the the SpinCount value is 33556432 or 0x020007d0. Does this value mean anything?
Maybe it's a CPU topology issue: all VMs emulate a dual single-core processor systems while the failures happen on single multi-core processor machines.
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine. Most likely it has to do with the different number of cores, spin-locking is only useful on multiprocessor systems. Nevertheless, is there any chance that we could also get a testbot VM with more than one core, to find such issues a bit earlier in the future? It could also be interesting for other synchronization related functions which might behave different on multiprocessor systems. -- 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=40191 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Sebastian Lackner from comment #3)
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine.
That's OK for now, but I don't think it can legitimately be considered broken. It looks like 0 means use a default spin count, which we'll probably want to support at some point. -- 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=40191 --- Comment #5 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to Alexandre Julliard from comment #4)
(In reply to Sebastian Lackner from comment #3)
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine.
That's OK for now, but I don't think it can legitimately be considered broken. It looks like 0 means use a default spin count, which we'll probably want to support at some point.
My understanding is that Wine currently targets more Win 7 than Win 8+, and there a value of 0 consistently sets SpinCount = 0, even on multicore systems (at least my systems, and I'm not aware of any test failures). Of course broken() doesn't mean that we'll not consider implementing it, when we change our focus to new Windows versions or have applications which depend on it. -- 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=40191 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Sebastian Lackner from comment #5)
My understanding is that Wine currently targets more Win 7 than Win 8+, and there a value of 0 consistently sets SpinCount = 0, even on multicore systems (at least my systems, and I'm not aware of any test failures). Of course broken() doesn't mean that we'll not consider implementing it, when we change our focus to new Windows versions or have applications which depend on it.
Wine does not "target" a Windows version, and there's no reason not to implement a Win8 behavior if it's considered useful. Of course we don't need this right now, and it's unlikely that an app is going to break because of this, so it doesn't make much difference. But in general, broken() should be only for things that we consider undesirable to implement, also in the future. -- 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=40191 --- Comment #7 from François Gouget <fgouget(a)codeweavers.com> --- I have done tests with the w8 QEMU VM and they confirmed that this issue is related to single-core vs. multi-core/hyperthreading: * The tests succeed on single-core processors, * and fail if the processor has either multiple cores or hyperthreading. With these tests I also discovered that Windows 8 (standard Home edition) will only use one processor, instead of up to two for all versions up to Windows 7. This means that currently all Windows 8+ VMs only use a single single-core processor. I have now changed the w8 VM configuration to a single dual-core non-hyperthreading processor. Here's the new result: https://testbot.winehq.org/JobDetails.pl?Key=20836 -- 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=40191 --- Comment #8 from François Gouget <fgouget(a)codeweavers.com> --- Final notes from my TestBot timeline: * Configuring a QEMU VM to have 'two logical CPUs' results in a dual processor machine by default. However regular versions of Windows (i.e. non-Pro / Enterprise) are restricted to only use a single CPU. They will start on multi-processor machines but make use of only one. This is not an issue for our Windows 7 VMs as Pro and Ultimate versions can use up to two processor. But our Windows 8 and 10 VMs use regular editions. So they need QEMU to be configured with a single multi-core processor instead to properly test 'SMP' configurations. * On Windows 8+ the SpinCount value of the RtlInitializeCriticalSectionEx() tests in ntdll:rtl is different on a multi-core or hyperthreaded CPU than on a single single-core non-hyperthreaded one. On Window s7 SpinCount is 0 no matter what the processor configuration: multi-processor, multi-core or hyperthreading. So this is a Windows 8+ thing. On Windows 8 SpinCount may also take non-zero values on systems with multiple single-core non-hyperthreaded processors but we cannot test that configuration. * I changed wtbw8 to use a single dual-core processor. wtbwvista, wtbw864 and wtbw1064 will need similar changes. -- 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=40191 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |dcf914857c1e29b64a31a67685b | |123a09db1bae1 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to François Gouget from comment #8)
Final notes from my TestBot timeline: * Configuring a QEMU VM to have 'two logical CPUs' results in a dual processor machine by default. However regular versions of Windows (i.e. non-Pro / Enterprise) are restricted to only use a single CPU. They will start on multi-processor machines but make use of only one. This is not an issue for our Windows 7 VMs as Pro and Ultimate versions can use up to two processor. But our Windows 8 and 10 VMs use regular editions. So they need QEMU to be configured with a single multi-core processor instead to properly test 'SMP' configurations. * On Windows 8+ the SpinCount value of the RtlInitializeCriticalSectionEx() tests in ntdll:rtl is different on a multi-core or hyperthreaded CPU than on a single single-core non-hyperthreaded one. On Window s7 SpinCount is 0 no matter what the processor configuration: multi-processor, multi-core or hyperthreading. So this is a Windows 8+ thing. On Windows 8 SpinCount may also take non-zero values on systems with multiple single-core non-hyperthreaded processors but we cannot test that configuration. * I changed wtbw8 to use a single dual-core processor. wtbwvista, wtbw864 and wtbw1064 will need similar changes.
We do not necessarily have to adjust all VMs, I think its just good to test with a big variety of different systems, to catch test failures as early as possible. Since http://source.winehq.org/git/wine.git/commit/dcf914857c1e29b64a31a67685b123a... the test failure should be gone, so marking this bug as FIXED. -- 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=40191 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.9.5. -- 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.
participants (1)
-
wine-bugs＠winehq.org