http://bugs.winehq.org/show_bug.cgi?id=28810
Bug #: 28810 Summary: d3dx9_36/tests/mesh.ok: D3DXLoadMeshTest fails under valgrind Product: Wine Version: 1.3.30 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com CC: wine-bugs@winehq.org Classification: Unclassified
Under Valgrind, "make mesh.ok" fails with mesh.c:2333: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2333: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2333: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2406: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2406: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2406: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff
This is on my i5 laptop, nvidia GeForce GTS 360M, NVIDIA 280.13. The test passes without valgrind.
http://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #1 from Rico kgbricola@web.de 2011-11-19 05:57:50 CST --- Created attachment 37530 --> http://bugs.winehq.org/attachment.cgi?id=37530 Buggy ok conversation test.
I discovered a similar problem, it doesn't have to do with valgrind or the mesh test, but I think it might have the same underlying problem.
Using a cast in the ok() macro seems to fail on some calls (see test). I'm not sure if that's a problem with the compiler or anything else. Attached is a small test case which triggers the bug on my system. Maybe someone else is able to reproduce it so that we could narrow down the wrong conversation.
Output with the my patch (wine d3dx9_36_test.exe.so buggy): buggy.c:31: Test failed: int 4, float 4 buggy.c:35: Test failed: 1ffffff buggy.c:37: Test failed: 1ffffff buggy.c:40: Test failed: 33554432.000000 33554431.000000
I'd expect that these values should be equal.
Note: Reordering the calls seems to solve the issue in some cases.
Dan: Could you try to convert the values to a temporary variable first and see if that helps?
http://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #2 from Dan Kegel dank@kegel.com 2011-11-19 07:34:35 CST --- I'm not sure this is related. I reduced your case to
#include <stdio.h> int main(int argc, char **argv) { int ivalue = 0x1ffffff; float res = ivalue; printf("%f %f\n", res, (float)ivalue); }
$ gcc -m32 buggy8.c $ ./a.out 33554432.000000 33554431.000000 $ gcc -m64 buggy8.c $ ./a.out 33554432.000000 33554432.000000 $ gcc -mfpmath=387 -m64 buggy8.c $ ./a.out 33554432.000000 33554431.000000 $ gcc -mfpmath=387 -ffloat-store -m64 buggy8.c $ ./a.out 33554432.000000 33554432.000000
$ perl -e 'print 0x1ffffff' 33554431
So: single precision floats aren't big enough to hold that integer precisely, but doubles are. You get the value 33554432.000000 whenever you really go through a single precision float. You get the value 33554431.000000 when the value stays as a double the whole way through, which it will in 387 mode if the compiler doesn't see any reason to reduce precision. I think.
You can get a mixed source and assembly listing if you want with gcc -m32 -Wa,-adhln -g buggy8.c
http://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #3 from Rico kgbricola@web.de 2011-11-19 09:07:34 CST --- Oh, nice explanation. Thank you.
Now let's describe, why I think this might be the same for your problem. There are only failing values which are theoretically big enough (b3ffffff). There is no conversation for exp_float but there might be one for got_float.
So if the path is "something special" the compiler might not convert to float (probably with valgrind) and without valgrind it might use the float value.
You may verify this with my test by commenting out e.g. the ok call in get_int2. That way you get the float as float: buggy.c:40: Test failed: 33554432.000000 33554432.000000
When the ok call is in you get the float as double: buggy.c:40: Test failed: 33554432.000000 33554431.000000
This happens without changing the gcc parameters! It's pure speculation that this might be the same problem but for me it looks a bit related, because changing some unrelated line changes the conversation. Valgrind might trigger the same...
Nevertheless I know where my problem comes from and how to resolve it.
Though, that doesn't solve your problem, sorry for the noise.
http://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #4 from Austin English austinenglish@gmail.com 2012-09-26 14:20:44 CDT --- mesh.c:2335: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2335: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2335: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2408: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2408: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2408: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff
mesh.c:9877: Test failed: Mesh 9: Got (0, 178, 128, 255) for vertex 1 diffuse, expected (0, 179, 128, 255). mesh.c:9877: Test failed: Mesh 13: Got (128, 178, 0, 255) for vertex 1 texture coordinates, expected (128, 179, 0, 255). mesh.c:9877: Test failed: Mesh 26: Got (178, 153, 128, 204) for vertex 4 diffuse, expected (179, 153, 128, 204). mesh.c:9877: Test failed: Mesh 26: Got (254, 252, 229, 255) for vertex 5 diffuse, expected (254, 252, 230, 255).
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #5 from Austin English austinenglish@gmail.com --- For me on mesa 10.0.4 / i965 / wine-1.7.16-178-g7e874ae
../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so mesh && touch mesh.ok preloader: Warning: failed to reserve range 00110000-68000000 preloader: Warning: failed to reserve range 7f000000-82000000 ==15782== Warning: client syscall munmap tried to modify addresses 0x81c81000-0x81c88fff intel_do_flush_locked failed: Input/output error make: *** [mesh.ok] Error 1
there were some leaks in d3dx9, and mesa has its own issues...
please retest.
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #6 from Austin English austinenglish@gmail.com --- After some mesa upgrades and suppressions, I can see this now: mesh.c:2345: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2345: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2345: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2418: Test failed: Vertex[7]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2418: Test failed: Vertex[11]: Expected diffuse b3ffffff, got b2ffffff mesh.c:2418: Test failed: Vertex[18]: Expected diffuse b3ffffff, got b2ffffff
10.1-6.20140305.fc20 / wine 1.7.18 / valgrind 3.9.0
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #7 from Austin English austinenglish@gmail.com --- Created attachment 48437 --> https://bugs.winehq.org/attachment.cgi?id=48437 backtrace
I got a crash today, backtrace attached.
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #8 from Dan Kegel dank@kegel.com --- The key lines:
Unhandled exception: page fault on write access to 0x81d9100c in 32-bit code (0x0400ae14). Backtrace: =>0 0x0400ae14 _vgr20180ZZ_libcZdsoZa_memcpy+0x1c4() in vgpreload_memcheck-x86-linux.so (0x04d6f298) 1 0x0737df14 in i965_dri.so (+0xf1f13) (0x81d91000) ... 6 0x07371dea in i965_dri.so (+0xe5de9) (0x04d6f618) 7 0x06dcfbd6 glTexSubImage2D+0x65() in libgl.so.1 (0x04d6f618) 8 0x05dca9d7 match_fbo_tex_update+0x2a6() in wined3d (0x04d6f618) 9 0x05dccaa2 wined3d_adapter_init.constprop+0x11d1() in wined3d (0x04d6fa78) 10 0x05dd2d79 wined3d_init+0x38(wined3d=0x481eaa0, flags=0xc) [dlls/wined3d/directx.c:5272] 11 0x05e58927 wined3d_create+0x66(flags=<?>) [dlls/wined3d/wined3d_main.c:105] 12 0x05d4e4af d3d9_init+0x3e(d3d9=0x48a9738, extended=0) [dlls/d3d9/directx.c:647] 13 0x05d41ab1 Direct3DCreate9+0x6b(sdk_version=<?>) [dlls/d3d9/d3d9_main.c:45] 14 0x04bb0b9e func_mesh+0x1f0d() [dlls/d3dx9_36/tests/mesh.c:2843] 15 0x04bd9a95 run_test+0x9e(name="mesh") [dlls/d3dx9_36/tests/../../../include/wine/test.h:584]
If i965_dri is an open source driver, do you have its debug symbols installed? Or is wine running into https://sourceware.org/bugzilla/show_bug.cgi?id=9538 ?
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #9 from Austin English austinenglish@gmail.com --- (In reply to Dan Kegel from comment #8)
The key lines:
Unhandled exception: page fault on write access to 0x81d9100c in 32-bit code (0x0400ae14). Backtrace: =>0 0x0400ae14 _vgr20180ZZ_libcZdsoZa_memcpy+0x1c4() in vgpreload_memcheck-x86-linux.so (0x04d6f298) 1 0x0737df14 in i965_dri.so (+0xf1f13) (0x81d91000) ... 6 0x07371dea in i965_dri.so (+0xe5de9) (0x04d6f618) 7 0x06dcfbd6 glTexSubImage2D+0x65() in libgl.so.1 (0x04d6f618) 8 0x05dca9d7 match_fbo_tex_update+0x2a6() in wined3d (0x04d6f618) 9 0x05dccaa2 wined3d_adapter_init.constprop+0x11d1() in wined3d (0x04d6fa78) 10 0x05dd2d79 wined3d_init+0x38(wined3d=0x481eaa0, flags=0xc) [dlls/wined3d/directx.c:5272] 11 0x05e58927 wined3d_create+0x66(flags=<?>) [dlls/wined3d/wined3d_main.c:105] 12 0x05d4e4af d3d9_init+0x3e(d3d9=0x48a9738, extended=0) [dlls/d3d9/directx.c:647] 13 0x05d41ab1 Direct3DCreate9+0x6b(sdk_version=<?>) [dlls/d3d9/d3d9_main.c:45] 14 0x04bb0b9e func_mesh+0x1f0d() [dlls/d3dx9_36/tests/mesh.c:2843] 15 0x04bd9a95 run_test+0x9e(name="mesh") [dlls/d3dx9_36/tests/../../../include/wine/test.h:584]
If i965_dri is an open source driver, do you have its debug symbols installed? Or is wine running into https://sourceware.org/bugzilla/show_bug.cgi?id=9538 ?
I built mesa from source rpm's, and tried installing the 32-bit and 64-bit rpms, but they don't seem to generate a proper backtrace.
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #10 from Austin English austinenglish@gmail.com --- Created attachment 48449 --> https://bugs.winehq.org/attachment.cgi?id=48449 nvidia backtrace
Happens on nvidia as well
https://bugs.winehq.org/show_bug.cgi?id=28810
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |valgrind
https://bugs.winehq.org/show_bug.cgi?id=28810
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #11 from Austin English austinenglish@gmail.com --- Still an issue in 1.7.43-40-gf479071 on intel/mesa.
https://bugs.winehq.org/show_bug.cgi?id=28810
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #12 from Austin English austinenglish@gmail.com --- Still in wine-1.7.51-225-g3966aff
https://bugs.winehq.org/show_bug.cgi?id=28810
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #13 from joaopa jeremielapuree@yahoo.fr --- What about this bug with current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=28810
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Austin English austinenglish@gmail.com --- Passing on my current (bumblebee) laptop, with intel and nvidia.
https://bugs.winehq.org/show_bug.cgi?id=28810
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc1.
-
wine-bugs＠winehq.org