February 2014 - Wine-devel - list.winehq.org

Re: urlmon: Fixed url.c tests on IE11.
by Marvin 27 Feb '14

27 Feb '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5243 Your paranoid android. === wxppro (32 bit url) === url.c:1669: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1878: Test failed: binding failed: 800c0005, expected 00000000 url.c:1889: Test failed: res = 00002efd, expected 00000000 url.c:3146: Test failed: expected OnProgress_SENDINGREQUEST url.c:3152: Test failed: expected OnResponse url.c:3156: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3157: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3158: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3170: Test failed: expected OnDataAvailable

2 1

Use of wined3d_mutex?
by Max TenEyck Woodbury 27 Feb '14

27 Feb '14

I have been looking at the use of the wined3d_mutex_lock and wined3d_mutex_unlock functions in the drawing code. I strongly suspect that it is being badly over-used. In particular, user call back functions are being called in several places with this mutex held. If the callback starts another thread to do something graphical where the thread needs the mutex, and then waits for the thread to finish, both threads will hang until the mutex times out. There are also places where a function that takes out the mutex is called with the mutex already held. Switching to another terminal window and back again sometimes breaks these deadlocks. It used to be that I had to do this several times doing a 'make test', but it just takes a long time now. (Yes, years ago I left the test running for several hours when I went out for a few hours and it was still hung when I got back. That does not happen now,) This shows up running Guild Wars 2. I have a CPU monitor running while I play and I can see the game chomping on both cores, except that the game will sometimes hang for 30-45 seconds and then resume. I am in the process of annotating the drawing routines use of the mutex, and there is simply a lot of code to go through. Could someone with a good understanding of the drawing part of wine comment please. In particular, are there places where the lock-like action of the reference counts can be used in place of taking out the mutex? max

3 2

Re: ws2_32/tests: Mark a SIOCATMARK test result as broken
by Marvin 27 Feb '14

27 Feb '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5238 Your paranoid android. === wxppro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFE4220C0 === w7pro64 (64 bit sock) === sock.c:622: Test failed: oob_server (98c): not at the OOB mark: 1

2 1

Re: [PATCH 1/2] d3dx9: Implement D3DXCreateBox()
by Henri Verbeet 27 Feb '14

27 Feb '14

I'm not really in charge of d3dx9, and I would've expected Matteo or Rico to write this instead, but here are some comments. On 27 February 2014 11:38, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > + static const float sign_x[24] = {-1.0f, -1.0f, -1.0f, -1.0f, -1.0f, -1.0f, 1.0f, 1.0f, > + 1.0f, 1.0f, 1.0f, 1.0f, -1.0f, -1.0f, 1.0f, 1.0f, > + -1.0f, 1.0f, 1.0f, -1.0f, -1.0f, -1.0f, 1.0f, 1.0f}; The explicit array size isn't needed, and I don't think it adds much for clarity. The indentation looks pretty arbitrary, the usual style for tables like these is to put the brace on a new line, and then indent the elements once. I.e.: static const float sign_x[] = { -1.0f, -1.0f, -1.0f, -1.0f, -1.0f, -1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, -1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, -1.0f, -1.0f, 1.0f, 1.0f, }; > + TRACE("(%p, %f, %f, %f, %p, %p)\n", device, width, height, depth, mesh, adjacency); I know d3dx9 isn't terribly consistent about this, but: TRACE("device %p, width %.8e, height %.8e, depth %.8e, mesh %p, adjacency %p.\n", device, width, height, depth, mesh, adjacency); > + hr = D3DXCreateMeshFVF(12, 24, D3DXMESH_MANAGED, D3DFVF_XYZ | D3DFVF_NORMAL, device, &box); > + > + if (FAILED(hr)) > + { > + return hr; > + } > + > + if (FAILED(hr = box->lpVtbl->LockVertexBuffer(box, 0, (void **)&vertices))) > + { > + box->lpVtbl->Release(box); > + return hr; > + } These are inconsistent. I'd prefer the second. > + for (i = 0; i < 24; i++) > + { > + vertices[i].position.x = width * sign_x[i]; > + vertices[i].position.y = height * sign_y[i]; > + vertices[i].position.z = depth * sign_z[i]; I suppose this works, but I think it would be clearer to store a unit box as an array of D3DXVECTOR3s, and then call D3DXVec3Scale() on the vectors. The "24" would then become "ARRAY_SIZE(unit_box)" as well. > + hr = D3DXCreateBuffer(36 * sizeof(DWORD), adjacency); > + > + if (FAILED(hr)) if (FAILED(hr = D3DXCreateBuffer(sizeof(adjacency_table), adjacency)))

1 0

Re: ws2_32/tests: Mark a SIOCATMARK test result as broken
by Bruno Jesus 27 Feb '14

27 Feb '14

On Thu, Feb 27, 2014 at 11:33 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > dlls/ws2_32/tests/sock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 2252245..3f27b02 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -610,7 +610,7 @@ static VOID WINAPI oob_server ( server_params *par ) > ok ( pos == -1, "simple_server (%x): test pattern error: %d\n", id, pos); > > ioctlsocket ( mem->sock[0].s, SIOCATMARK, &atmark ); > - ok ( atmark == 1, "oob_server (%x): unexpectedly at the OOB mark: %i\n", id, atmark ); > + ok ( atmark == 1 || broken(atmark == 0), "oob_server (%x): unexpectedly at the OOB mark: %i\n", id, atmark ); There is other test failing too, right? At least for me. So this would only "solve" half of the problem. What we need to do IMO is simplify the test using a more sequential way to ensure normal and OOB data does not get mixed. Regards, Bruno

1 0

ddraw/tests: Don't crash after a failed CreateSurface() call.
by Francois Gouget 27 Feb '14

27 Feb '14

So there are a number of CreateSurface() calls that fail and these are causing the tests to crash. For instance for ddraw2: http://test.winehq.org/data/tests/ddraw:ddraw2.html Is there a way to check what surface types are supported? create_device() calls EnumDevices() but finding a match clearly does not guarantee we'll be able to create a surface given the error we get there (but presumably that check was more for the following CreateDevice() call). I tried using EnumSurfaces() but without much luck. I'm also a bit worried that DDENUMSURFACES_MATCH is not used anywhere in Wine (*). Alternatively we can just react to failing CreateSurface() calls and clean up + abort a bit like is done in the following patch. (*) Also the DDENUMSURFACES_{SEARCH,MATCH}TYPE macros found in dlls/ddraw/ddraw.c are not used anymore since c8901d6f. diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c index 5a3bd77..2a5a9c4 100644 --- a/dlls/ddraw/tests/ddraw2.c +++ b/dlls/ddraw/tests/ddraw2.c @@ -227,7 +227,7 @@ static IDirect3DDevice2 *create_device(IDirectDraw2 *ddraw, HWND window, DWORD c surface_desc.dwWidth = 640; surface_desc.dwHeight = 480; hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &ds, NULL); - ok(SUCCEEDED(hr), "Failed to create depth buffer, hr %#x.\n", hr); + ok(SUCCEEDED(hr) || broken(hr == DDERR_INVALIDPIXELFORMAT), "Failed to create depth buffer, hr %#x.\n", hr); if (FAILED(hr)) { IDirect3D2_Release(d3d); @@ -4451,6 +4451,8 @@ static void test_surface_lock(void) hr = IDirectDraw2_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, type %s, hr %#x.\n", tests[i].name, hr); + if (FAILED(hr)) + continue; memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); @@ -4817,6 +4819,8 @@ static void test_set_surface_desc(void) hr = IDirectDraw2_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + goto done; hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface3, (void **)&surface3); ok(SUCCEEDED(hr), "Failed to get IDirectDrawSurface3 interface, hr %#x.\n", hr); @@ -5113,6 +5117,12 @@ static void test_user_memory_getdc(void) ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY; hr = IDirectDraw2_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + { + IDirectDraw2_Release(ddraw); + DestroyWindow(window); + return; + } hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface3, (void **)&surface3); ok(SUCCEEDED(hr), "Failed to get IDirectDrawSurface3 interface, hr %#x.\n", hr); diff --git a/dlls/ddraw/tests/ddraw4.c b/dlls/ddraw/tests/ddraw4.c index 81c043c..5da4a71 100644 --- a/dlls/ddraw/tests/ddraw4.c +++ b/dlls/ddraw/tests/ddraw4.c @@ -5423,6 +5423,12 @@ static void test_set_surface_desc(void) hr = IDirectDraw4_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + { + IDirectDraw4_Release(ddraw); + DestroyWindow(window); + return; + } reset_ddsd(&ddsd); ddsd.dwFlags = DDSD_LPSURFACE; @@ -5715,6 +5721,12 @@ static void test_user_memory_getdc(void) ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY; hr = IDirectDraw4_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + { + IDirectDraw4_Release(ddraw); + DestroyWindow(window); + return; + } memset(data, 0xaa, sizeof(data)); reset_ddsd(&ddsd); diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c index 8e01238..4735fca 100644 --- a/dlls/ddraw/tests/ddraw7.c +++ b/dlls/ddraw/tests/ddraw7.c @@ -5301,6 +5301,12 @@ static void test_set_surface_desc(void) hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + { + IDirectDraw7_Release(ddraw); + DestroyWindow(window); + return; + } reset_ddsd(&ddsd); ddsd.dwFlags = DDSD_LPSURFACE; @@ -5594,6 +5600,12 @@ static void test_user_memory_getdc(void) ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY; hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + if (FAILED(hr)) + { + IDirectDraw7_Release(ddraw); + DestroyWindow(window); + return; + } memset(data, 0xaa, sizeof(data)); reset_ddsd(&ddsd);

2 1

Re: d3d9/tests: Fix some test failures on Windows 2000.
by Henri Verbeet 27 Feb '14

27 Feb '14

On 24 February 2014 23:54, Francois Gouget <fgouget(a)codeweavers.com> wrote: > --- > > This fixes some tests on the WineTestBot VM. > > dlls/d3d9/tests/device.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > Most of the IDirect3D9_CreateDevice() calls in device.c should be calls to create_device() instead. (And then just skip() if it fails to create a device.) I think the only exceptions are test_fpu_setup() and test_swvp_buffer().

2 2

Re: ddraw/tests: Probe the supported display modes and skip tests based on the result.
by Henri Verbeet 27 Feb '14

27 Feb '14

On 27 February 2014 02:24, Francois Gouget <fgouget(a)codeweavers.com> wrote: > * QEmu can emulate an old Cirrus 5446 graphics card that tops out at > 24bpp and thus does not support the 32bpp modes we want. For Windows > 2000 that's all that works. > For most of these tests, perhaps all of them, we don't care about the difference between 24 and 32 bpp modes. I'm going to look into writing a small set_display_mode() helper that just tries both, which would allow these tests to be run on the Windows 2000 testbot as well. That doesn't help for 8 bpp modes, but there are only a few tests that need those, and I think the way we handle those currently is fine.

1 0

Re: [PATCH 1/5] wined3d: Decouple private data from the resource structure (try 2).
by Henri Verbeet 27 Feb '14

27 Feb '14

> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 0ceb6f1..c7c420a 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1976,6 +1976,19 @@ static inline void context_invalidate_active_texture(struct wined3d_context *con > context_invalidate_state(context, STATE_SAMPLER(sampler)); > } > > +struct wined3d_privstore > +{ > + struct list content; > +}; > + > +void wined3d_privstore_init(struct wined3d_privstore *store) DECLSPEC_HIDDEN; > +void wined3d_privstore_cleanup(struct wined3d_privstore *store) DECLSPEC_HIDDEN; > +HRESULT wined3d_privstore_free_private_data(struct wined3d_privstore *store, const GUID *guid); > +HRESULT wined3d_privstore_get_private_data(const struct wined3d_privstore *store, > + const GUID *guid, void *data, DWORD *data_size, DWORD *flags) DECLSPEC_HIDDEN; > +HRESULT wined3d_privstore_set_private_data(struct wined3d_privstore *store, > + const GUID *guid, const void *data, DWORD data_size, DWORD flags) DECLSPEC_HIDDEN; > + > #define WINED3D_RESOURCE_ACCESS_GPU 0x1 > #define WINED3D_RESOURCE_ACCESS_CPU 0x2 > Perhaps this should just be a set of inline helpers in something like include/wine/wined3d_util.h, or possibly wined3d.h, similar to e.g. include/wine/list.h. I'm not really a fan of the name wined3d_privstore. I suppose wined3d_private_store would be slightly preferable, but I don't think that's particularly great either.

1 0

Re: ddraw/tests: Probe the supported display modes and skip tests based on the result.
by Stefan Dösinger 27 Feb '14

27 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-27 02:24, schrieb Francois Gouget: > * HD4000 : Intel they decided that 256 color modes are obsolete > (they are) and not worth supporting. Out of curiosity, does that system run old game classics like Age of Empires 2 or old StarCraft 1? If so, how? If not, I'd consider that a pretty bad non-feature. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTDvTdAAoJEN0/YqbEcdMw+lcP/j5K7N52A6J6WhLqpSZrP7Ha AbptP8Z9L+O0G33rZlUbZAsT8w64aTDXjKL9ahIua9ia+lxl55JJaD9ectiV8clo 22PNXK1CdubY3pIrwKdlax0f+hM5ZqTOBN6gaG1th/CTau8SqXSI3scJZDoimnJO 9UQpwYj6smghh3uQhYx62KJKPDe3Ek9zgAMKRdkWRGc5P4zL/tk4uwGYm8CGM8Oy eAg9tthRUwDeYUaQ/MPdAOO82T42Z9WLEvJO+zk/VNr23P7E+H4WoYAuM9JMM1dP 8/x6CM7hmVrz8sE45wgpxrD/IDzZtIIzEBndjojhBEp2bctEIUJADKk23zGnIxHy 87OotuP7BFgrtZG0vXWO2eOV1xmcdXWdhZaHYzG8MDHLsUwLBgzL49gC5wA+UHL3 ad/IhIr+ok9wx1dXJYMrLfrPG05x93f1CmeNnPXU7gv1z/pQ+VoLbIvhsvlLUdap 9mmJC9ogbBju7whb+aNF1SAi/JrE4IkohiDkGvii2vWB4eGpOUCxKfhriEyJTKRQ iEjcWzxZ0d9CzDA0Lhe18ia8LoUafDvY9U/Q6c6fWhA/xt8ysTvgU+CmfiFNg9xN cYGkZSEaFMrq9mWfTRAdi/Kl7ZJ2DgOZGq3hKHm5XSd4rKkLlAWOpELiycpl8tqQ gaOLXi9E/iShT2ECIEu5 =AGOH -----END PGP SIGNATURE-----

1 0