http://bugs.winehq.org/show_bug.cgi?id=28301
Summary: ddraw visual tests are flaky Product: Wine Version: 1.3.27 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
In about one run out of a hundred, ddraw's visual test failed here. Log:
../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok ... visual.c:1497: Test failed: Got color 00000000, expected 00000080 or near visual.c:1503: Test failed: Got color 00000000, expected 000000ff or near visual.c:1509: Test failed: Got color 00000000, expected 00000080 or near visual.c:1515: Test failed: Got color 00000000, expected 000000ff or near visual.c:1891: Tests skipped: device has no P8 texture support, skipping test
The system it misbehaved once on is: os: Ubuntu 11.04, 2.6.38-11-generic-pae, pulseaudio 0.9.22-24-g67d18, Advanced Linux Sound Architecture Driver Version 1.0.23. ram: 4020 MB cpu: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz gpu: GeForce GT 220/PCI/SSE2 3.3.0 NVIDIA 270.41.06 The system is running a little warm (cpu 73 degrees C, but well below critical)
I see a number of systems which have similar errors listed at: http://test.winehq.org/data/tests/ddraw:visual.html
http://bugs.winehq.org/show_bug.cgi?id=28301
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-07 03:33:32 CDT --- I'll look at it. Out of curiosity, what happens when you run the tests in Valgrind?
I'm currently struggling with the test result viewer. Do the tests fail on Windows as well every now and then?
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-07 03:34:43 CDT --- Yep, they fail on Windows as well, so the bug is most likely in the tests
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #3 from Dan Kegel dank@kegel.com 2011-09-07 08:42:17 CDT --- Just saw another failure mode on the same machine:
visual.c:2551: Test failed: got R FF G 00 B 00, expected R 00 G FF B 00 err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems fixme:d3d_surface:IWineD3DSurfaceImpl_BltOverride Unsupported blit operation falling back to software visual.c:2616: Test failed: got R FF G 00 B 00, expected R 00 G FF B 00 fixme:d3d_surface:IWineD3DSurfaceImpl_BltOverride Unsupported blit operation falling back to software visual.c:2646: Test failed: got R FF G 00 B 00, expected R 00 G FF B 00 (And the full log is at http://buildbot.kegel.com/builders/runtests-default/builds/34, at least for a little while.)
as well as another instance of the first failure mode, http://buildbot.kegel.com:8010/builders/runtests-default/builds/38
Looking solely at this machine, that's three failures in the current set of 60 runs, so I might be able to verify any proposed fix in an hour or two.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #4 from Dan Kegel dank@kegel.com 2011-09-07 11:32:09 CDT --- And another instance on same hardware: http://buildbot.kegel.com/builders/runtests-default/builds/70
../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok fixme:win:EnumDisplayDevicesW ((null),0,0x32f56c,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided err:d3d:wined3d_device_uninit_3d Something is still holding a reference to depth/stencil buffer 0x163cb8. fixme:win:EnumDisplayDevicesW ((null),0,0x32f53c,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats visual.c:1497: Test failed: Got color 00000000, expected 00000080 or near visual.c:1503: Test failed: Got color 00000000, expected 000000ff or near visual.c:1509: Test failed: Got color 00000000, expected 00000080 or near visual.c:1515: Test failed: Got color 00000000, expected 000000ff or near visual.c:1618: Test failed: Got color 00000000, expected 000000ff or near visual.c:1624: Test failed: Got color 00000000, expected 000000ff or near visual.c:1630: Test failed: Got color 00000000, expected 00000080 or near visual.c:1636: Test failed: Got color 00000000, expected 00000080 or near visual.c:1740: Test failed: Got color 00000000, expected 00ff0040 or near visual.c:1746: Test failed: Got color 00000000, expected 00ff0080 or near visual.c:1752: Test failed: Got color 00000000, expected 00800080 or near visual.c:1758: Test failed: Got color 00000000, expected 008000ff or near visual.c:1869: Test failed: Got color 00000000, expected 00ff0000 or near visual.c:1878: Test failed: Got color 00000000, expected 00800000 or near visual.c:1891: Tests skipped: device has no P8 texture support, skipping test visual.c:2110: Test failed: Got color 00000000, expected 00ff0000 visual.c:2118: Test failed: Got color 00000000, expected 000000ff fixme:ddraw:IDirect3DDeviceImpl_7_Release Texture handle 0x2 (0x1b4ba8) not unset properly. fixme:win:EnumDisplayDevicesW ((null),0,0x32f47c,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats visual.c:2350: Test failed: Got color 00000000, expected 0000ff00 visual.c:2356: Test failed: Got color 00000000, expected 00ff0000 visual.c:2387: Test failed: Got color 00000000, expected 00ffffff
I guess I'll blacklist it tonight.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 15:50:27 CDT --- I could reproduce the first two failure modes you listed on Windows, so the bug is in the test, not ddraw. I'm no closer to a solution yet though.
Did you try to run the tests in Valgrind?
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #6 from Austin English austinenglish@gmail.com 2011-09-12 16:09:34 CDT --- (In reply to comment #5)
I could reproduce the first two failure modes you listed on Windows, so the bug is in the test, not ddraw. I'm no closer to a solution yet though.
Did you try to run the tests in Valgrind?
http://austinenglish.com/logs/valgrind/2011-09-09-14.59/vg-ddraw_visual.txt
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #7 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 16:42:06 CDT --- I've no clue yet what is going on.
What seems to happen in the p8_primary_test() is that the palette is broken. Color 0 should be red(0x00ff0000), color 1 green(0x0000ff00) and color 2 blue(0x000000ff). What happens is that color 0 is black, color 1 is a dark red(0x00800000) and color 2 is a dark green(0x00008000).
The problem is not related to the other tests. I disabled the others and started the p8_primary_test function directly and the problem still shows up.
Sometimes the first test(clear using p8_surface_fill_rect) succeeds, and the 2nd one fails. The fill_rect call is not needed to reproduce the issue, the colorfill blit alone can fail too.
Filling the surface again doesn't produce the proper color, so the problem is not that the blit is silently ignored.
The surface isn't lost and GetPalette returns the correct palette. However, reapplying the ddraw palette twice fixes the issue.
The wrong color shows up on the screen as well, so it is not a problem of the readback code.
Again, this is on Windows. I'd suspect some brokeness in native ddraw, but apparently the same test is failing on Wine(Although with different, more sane colors).
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #8 from Dan Kegel dank@kegel.com 2011-09-12 16:46:13 CDT --- Can you mark the test as interactive (or broken) until it's fixed?
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #9 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 16:47:41 CDT --- Austin, your comment collided with mine, but thanks for the Valgrind log. Unfortunately the Valgrind call doesn't get anywhere near to the failing tests, and the place where it chokes isn't necessary to trigger the failures here.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #10 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 16:48:24 CDT --- broken won't help buildbot - broken is only for Windows systems. Interactive would, but we could as well disable it entirely.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #11 from Austin English austinenglish@gmail.com 2011-09-12 17:25:44 CDT --- (In reply to comment #9)
Austin, your comment collided with mine, but thanks for the Valgrind log. Unfortunately the Valgrind call doesn't get anywhere near to the failing tests, and the place where it chokes isn't necessary to trigger the failures here.
That machine also uses mesa from git, not nvidia drivers, but I figured it was better than nothing :).
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #12 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 18:10:57 CDT --- Created an attachment (id=36346) --> (http://bugs.winehq.org/attachment.cgi?id=36346) Run only the D3D1_TextureMapBlendTest tests
The first failure mode looks like a interaction problem between the tests. Dan, can you verify this on your machines with this patch? It's obviously not a correct fix, but if my theory is correct the previously flaky test should pass reliably now. It works for me on Windows at least.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #13 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-12 18:12:36 CDT --- Btw, the 3rd failure mode looks like an extended version of the first. The same set of tests fail. The first failing tests are the same, and the additional tests are immediately following tests. In both cases it looks like the intended draws do not happen(the result color is black), or the readback fails.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #14 from Dan Kegel dank@kegel.com 2011-09-12 18:20:20 CDT --- yes, I will try that tonight.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #15 from Dan Kegel dank@kegel.com 2011-09-13 00:05:34 CDT --- On the affected (and rather hot) system: With that patch, the test passes. Without it, it fails reliably.
http://bugs.winehq.org/show_bug.cgi?id=28301
--- Comment #16 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-13 17:31:55 CDT --- I can't reproduce the first failure mode on Windows today(I've seen it twice yesterday).
Can you try to pinpoint the problem a bit more, by re-enabling some calls *before* the D3D1_createObjects() call? The most likely thing that might trigger the bug again is the createObjects/releaseObjects pair.
http://bugs.winehq.org/show_bug.cgi?id=28301
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-ddraw |directx-d3d
https://bugs.winehq.org/show_bug.cgi?id=28301
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #17 from Austin English austinenglish@gmail.com --- (In reply to Stefan Dösinger from comment #16)
I can't reproduce the first failure mode on Windows today(I've seen it twice yesterday).
Can you try to pinpoint the problem a bit more, by re-enabling some calls *before* the D3D1_createObjects() call? The most likely thing that might trigger the bug again is the createObjects/releaseObjects pair.
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=28301
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org