Should fix https://bugs.winehq.org/show_bug.cgi?id=51827
I tested this on a Windows 10 VM. With last=4 it failed about 50% of the time, with last=3 it passed 100 tests without any failures.
From: Sven Baars sbaars@codeweavers.com
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51827 Signed-off-by: Sven Baars sbaars@codeweavers.com --- dlls/d3dx10_43/tests/d3dx10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/d3dx10_43/tests/d3dx10.c b/dlls/d3dx10_43/tests/d3dx10.c index 9b7a4d7cc9b..15656a2919d 100644 --- a/dlls/d3dx10_43/tests/d3dx10.c +++ b/dlls/d3dx10_43/tests/d3dx10.c @@ -2467,7 +2467,7 @@ static void test_font(void) ok(hr == S_OK, "Unexpected hr %#x.\n", hr);
/* Test glyphs that are not rendered */ - hr = ID3DX10Font_PreloadGlyphs(font, 0, 5); + hr = ID3DX10Font_PreloadGlyphs(font, 0, 3); todo_wine ok(hr == S_OK, "Unexpected hr %#x.\n", hr);
This kind of behavior is very suspicious. FWIW the same test was already reduced by 1c7323b1926dbab4c81fd4b22b04d330459c3748. It seems like that PreloadGlyphs() call causes some kind of memory corruption issue in native or something like that.
Can you try to figure out if that's the case and e.g. whether changing the parameters make the issue go away? Depending on the results we might want to put the test inside an if (0){}, with a small comment explaining the details.
On Tue May 10 19:22:16 2022 +0000, Matteo Bruni wrote:
This kind of behavior is very suspicious. FWIW the same test was already reduced by 1c7323b1926dbab4c81fd4b22b04d330459c3748. It seems like that PreloadGlyphs() call causes some kind of memory corruption issue in native or something like that. Can you try to figure out if that's the case and e.g. whether changing the parameters make the issue go away? Depending on the results we might want to put the test inside an if (0){}, with a small comment explaining the details.
I agree that it is very suspicious. For me (0, 1000), (0, 3), (7, 10) and (997, 1000) actually work on my Windows 10 VM, but (0, 4), (0, 10), (6, 10) and (996, 1000) fail. So it seems like at least using only 4 glyphs works. The test with (0, 1000) got patched before, so that must be broken on some testbot VMs as well. I initially added the (0, 1000) in the d3dx9 side to test whether it could load more glyphs than there are glyphs that fit on the first texture. Using (0, 5) already doesn't serve that purpose anymore, so we may as well make it (0, 3) or any other 4 glyphs.
The reason could be that there is a bug in the Morton encoding in d3dx10_34, but of course that's all speculation. Note that it seems to have gotten fixed in d3dx10_35 and works in any version thereafter. So disabling the test seems like a waste.
Ah, I didn't realize (or I forgot) that the bug only applies to exactly d3dx10_34. Then I guess we should try to restore the original (0, 1000) and just skip the test if (D3DX10_SDK_VERSION == 34). Which we don't define at the moment. We should probably define that in the various d3dx10_xx/tests/ makefiles, like we already do for D3D_COMPILER_VERSION for d3dcompiler / d3d10.
-
Matteo Bruni (＠Mystral) -
Sven Baars
-
Sven Baars (＠sbaars)