April 2014 - Wine-Devel - list.winehq.org

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Ken Thomases

On Apr 5, 2014, at 7:36 PM, Daniel Horn wrote: > What about using a lighter weight locking primitive such as one that does not require a syscall? When it's not under contention, the critical section implementation ought to avoid syscalls already. When it is under contention, it's pretty unavoidable that syscalls will be necessary. (A critical section can use a spinlock to put that off for a bit if the thread that owns the lock will be done with it very quickly. That might help in the common case where the fd is found in the cache _if_ the problem is contention over the critical section. That's a big "if".) However, I think the real issue is the calls to pthread_sigmask() in server_{enter,leave}_uninterrupted_section(). I think those are necessary to prevent the wineserver from suspending the thread while it holds the critical section and thus deadlocking with other threads. I don't know if anything can be done about that. It might be possible to have a safe, lockless version of get_cached_fd() that sometimes produces a false-negative. Then, if it fails, you'd enter the uninterrupted section and try the reliable version before making the server call. Devising such a scheme and convincing us that it's safe and reliable is the hard part. It might be sufficient put a memory barrier before the lookup of the fd in get_cached_fd() and then something like this at the bottom of that block: if (interlocked_cmpxchg( &fd_cache[entry][idx].fd, fd + 1, fd + 1) != fd + 1) fd = -1; The idea is to verify that the fd has not been replaced or removed after we fetched it and its properties. (There's a chance that server_remove_fd_from_cache() is called after we make that check and then the caller of server_remove_fd_from_cache() closes the fd. And the fd could be reused for something else. However, as near as I can tell, that's already possible with server_get_unix_fd() as it stands.) It's very possible that this scheme has a hole that I've missed. Getting this sort of thing right is notoriously difficult. -Ken

April 5, 2014

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Daniel Horn

What about using a lighter weight locking primitive such as one that does not require a syscall?- Daniel On Sat, Apr 5, 2014 at 5:24 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Apr 5, 2014, at 5:25 PM, Daniel Horn wrote: >> The call to server_enter_uninterrupted_section in server_get_unix_fd >> was causing 2 million syscalls over the span of several seconds when >> launching many popular application suites and it was causing >> significant performance overhead. >> >> Switching those two lines resolves the problem entirely because the >> cache is sized such that it nearly never misses. > You can't call get_cached_fd() without entering the critical section because the critical section is protecting the fd cache. Your patch opens the code up to race conditions and data inconsistency. > -Ken

April 5, 2014

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits

by Ken Thomases

On Apr 5, 2014, at 5:25 PM, Daniel Horn wrote: > The call to server_enter_uninterrupted_section in server_get_unix_fd > was causing 2 million syscalls over the span of several seconds when > launching many popular application suites and it was causing > significant performance overhead. > > Switching those two lines resolves the problem entirely because the > cache is sized such that it nearly never misses. You can't call get_cached_fd() without entering the critical section because the critical section is protecting the fd cache. Your patch opens the code up to race conditions and data inconsistency. -Ken

April 5, 2014

Re: po: Revise Russian translation

by Nikolay Sivov

On 4/5/2014 18:17, Dmitry Timoshkov wrote: > Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> Looks good. I especially like changes like these: >> >> --- >> -msgstr "Пожалуйста, выберите файл." >> +msgstr "Выберите файл." > No, this doesn't match the original english text. I matches okay and sounds better. Verb form is already in plural which makes 'please' redundant. Same thing as for 'Вы' garbage when used to address one person. > Some other translations > don't match either, for instance > >> "This large number of copies is not supported by your printer.\n" >> "Please enter a value between 1 and %d." >> msgstr "" >> -"Такое большое количество копий не может быть напечатано вашим принтером.\n" >> +"Такое большое количество копий не может быть напечатано этим принтером.\n" >> What you mean? 'your' translated literally is out of place here. Article or a possessive pronoun before a noun is not a requirement in Russian, as I'm sure you know. In this particular phase it would be enough to say 'не поддерживается принтером'. No need to literally match English variant.

April 5, 2014

Re: po: Revise Russian translation

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Looks good. I especially like changes like these: > > --- > -msgstr "Пожалуйста, выберите файл." > +msgstr "Выберите файл." No, this doesn't match the original english text. Some other translations don't match either, for instance > "This large number of copies is not supported by your printer.\n" > "Please enter a value between 1 and %d." > msgstr "" > -"Такое большое количество копий не может быть напечатано вашим принтером.\n" > +"Такое большое количество копий не может быть напечатано этим принтером.\n" -- Dmitry.

April 5, 2014

Re: po: Revise Russian translation

by Nikolay Sivov

Looks good. I especially like changes like these: --- -msgstr "Пожалуйста, выберите файл." +msgstr "Выберите файл." ---

April 5, 2014

Re: [PATCH 5/5] ddraw/tests: Add mipmap locking tests.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6163 Your paranoid android. === w8 (32 bit ddraw2) === Failure running script in VM: timed out waiting for the child process === w8 (32 bit ddraw1) === ddraw1.c:3968: Test failed: Got unexpected refcount 3. ddraw1.c:3987: Test failed: Got unexpected refcount 3. ddraw1.c:3994: Test failed: Got unexpected hr 0. ddraw1.c:3997: Test failed: Got unexpected refcount 3. ddraw1.c:3999: Test failed: Got unexpected refcount 2. ddraw1.c:4005: Test failed: Got unexpected hr 0. ddraw1.c:4008: Test failed: Got unexpected refcount 2. ddraw1.c:4010: Test failed: Got unexpected refcount 1. === w8 (32 bit ddraw7) === ddraw7.c:5604: Test failed: Got unexpected refcount 3. ddraw7.c:5623: Test failed: Got unexpected refcount 3. ddraw7.c:5630: Test failed: Got unexpected hr 0. ddraw7.c:5633: Test failed: Got unexpected refcount 3. ddraw7.c:5635: Test failed: Got unexpected refcount 2. ddraw7.c:5641: Test failed: Got unexpected hr 0. ddraw7.c:5644: Test failed: Got unexpected refcount 2. ddraw7.c:5646: Test failed: Got unexpected refcount 1. ddraw7.c:5648: Test failed: Got unexpected refcount 6. ddraw7.c:5765: Test failed: Failed to set cooperative level, hr 0x8876023b. === wvistau64 (64 bit ddraw7) === Unable to set the VM system time: the "nc -q0 '10.42.42.238' '4242'" command returned 1 === w2000pro (32 bit ddraw4) === Unable to set the VM system time: the "nc -q0 '10.42.42.139' '4242'" command returned 1

April 4, 2014

Re: [PATCH 2/2] d3d8/tests: Test locking of mipmap textures.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6166 Your paranoid android. === build (build) === Patch failed to apply

April 4, 2014

Re: [PATCH 1/2] d3d9/tests: Test locking of mipmap textures.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6165 Your paranoid android. === build (build) === Patch failed to apply

April 4, 2014

Re: [PATCH 4/5] d3d8/tests: Test locking of mipmap textures.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6162 Your paranoid android. === w8 (32 bit device) === device.c:2396: Test failed: Expected foreground window 0006019E, got 00010048. device.c:3038: Test failed: Expected wndproc 0x412120, got 0x412120.

April 4, 2014

Re: [PATCH 2/5] d3d8/tests: Add a test for (sub-) resource types.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6160 Your paranoid android. === w8 (32 bit device) === device.c:2396: Test failed: Expected foreground window 000501D8, got 00010048. device.c:3038: Test failed: Expected wndproc 0x412120, got 0x412120.

April 4, 2014

Re: [PATCH 3/5] d3d9/tests: Test locking of mipmap textures.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-04 12:23, schrieb Henri Verbeet: > On 4 April 2014 11:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 2, 0, D3DFMT_X8R8G8B8, >> + D3DPOOL_DEFAULT, &texture_dst, NULL); >> + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); >> + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst); >> + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); >> + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst2); >> + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); >> + > This gets two references to the same surface level, is that intentional? No, the second one should pass level 1. >> + hr = IDirect3DDevice9_UpdateSurface(device, surface, NULL, surface_dst, NULL); >> + ok(SUCCEEDED(hr), "Failed to update surface, hr %#x.\n", hr); >> + hr = IDirect3DDevice9_UpdateSurface(device, surface2, NULL, surface_dst2, NULL); >> + todo_wine ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); >> + > Doesn't this just fail because the surface sizes are different? > (Although I would have expected this to work.) I re-checked this, it indeed fails because the source is locked and not because the destination is wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPo7VAAoJEN0/YqbEcdMwZi4QAIxotIMQybguTKcQR9eDCEqI dqdEx9FpXBZfq/9gUzPAw1xS6nNpZ623J+7BvfzpWs15eQbO0A+Vm1PcpXHA3D2T hjQ82WDzZ1WFQ4kimASoK3hWWTQhToyREueLFcu3/T1wKYZ8jk3UYcAIhDRbHUwd HqXniZ2V/KPEXuRxj/9ZjCS7z3wa0qZyvCI8WsOijjJJ0hUTKz3bvdfO2x18hB9Z r2MsNu6TtHkRRnrf++6XsrUW7RMGIJi+jLeWXwjgxq7C2EmZrGIGMwXknsaj5jpA EOCvQ8z2J2/Qm45bo4OVILKEWR6XaXgwOSVj1fK1RpCHyKbLWiifpmt0t0hrr0Jm a60U7S9xV7tb1AuwcZcF8VV5bDvwfMgsk2+3iRWkioGlN5krS7UxxVjiG2RqobnD zmscuqS4GOQcrYnicGoOErviq+52d36u+33364Ki0pZLLTUp3wshcWo00ozLYc5f z5mq0WDbKxx8ONbQr3XKwD17T3t4rwVGbCvbopQdBS1S8SftLImC8T5/F4FBuqRc xEyGRDGFNQwY6wAa8gf2oQhnaOsjl63XG11zr5VZEVmgSeQ/4Z8iFYpTksx5XrSs XHHhNHbDsnelCZn1o6QAq/5b6u0zuugs6oa9XZvpS/smsR84FDYlZ1sS4sBs6vpn hAKU7is/cBt+Td+YDllg =1Xiv -----END PGP SIGNATURE-----

April 4, 2014

Re: [PATCH 3/5] d3d9/tests: Test locking of mipmap textures.

by Henri Verbeet

On 4 April 2014 11:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 2, 0, D3DFMT_X8R8G8B8, > + D3DPOOL_DEFAULT, &texture_dst, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst); > + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); > + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst2); > + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); > + This gets two references to the same surface level, is that intentional? > + hr = IDirect3DDevice9_UpdateSurface(device, surface, NULL, surface_dst, NULL); > + ok(SUCCEEDED(hr), "Failed to update surface, hr %#x.\n", hr); > + hr = IDirect3DDevice9_UpdateSurface(device, surface2, NULL, surface_dst2, NULL); > + todo_wine ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + Doesn't this just fail because the surface sizes are different? (Although I would have expected this to work.)

April 4, 2014

Re: [PATCH] ddraw: add dsurface dimension tests, try 7

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-04 09:43, schrieb Stefan Dösinger: > Hi, > > Thanks for the patch. I'll test it on my Windows boxes as soon as > they're done with Linux updates (Gentoo...) and report any failures > I find. And the test results are in - at least on Windows 7 + Nvidia: The 32 bit tests pass. If built with Win64, test 9 succeeds with D3DFMT_P8. The surface is 4 GB in size, and my machine has 16 GB of physical memory and I think swap is enabled as well. I think the R5G6B5 test should succeed as well, but for some reason it doesn't. I recommend to drop the out of memory tests from this patch. If I understand the original problem correctly the test is not needed for what you actually want to fix. You can add it in a separate patch if you want to. Unfortunately my 3 Radeon boxes aren't working at the moment :-\ . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPmgHAAoJEN0/YqbEcdMwMwYP/A8Nqv1DNEkqbUQNvfy0cngp S7GO1+kM6gg7ATMZx9aZe6mSKCDMKMgiDmtpNu0YvOQrupWuvQxN7/j8UctdL3Wu 49d9WwnbkHNMV3LrQgYkGd+AwKcPGyNul/Epk/LJUEueBq7AmC/SmWDdlbUQEMd6 rKhgnkibxtXmVd4xHUEMEaAcUeh/PE1HrQtCqFyQnaPoL8SkeCzq6niU7n+qPkd1 AUZhImG3TeSxFR3Go8B1isfmzPc+fUFMIZdIN3JSTdpuJJDy4e6OlcP8Obw3W11V LP5TrHxRoSB7KbeV4r+h90/Z9bkSW9JJBL86X06lW2s2R9njytuuOW6kek7wiJlJ Guz1YetP6FxOb34d3ktAjNsqqO+KB01kJM8MIRgwNt4jxHjyT7MgWbIxA9VJxlbK y/7epq5Ntsfy3ZPbHoATqyAvUSX4EBhQiN7no3i6S5KSLr4djZoQDUomwBwm+kSG H8tmwh5SG+vDunzKC7rkizpgHI2ZOJNXxd7EMP+oYQbwOSXB8nVdQt+2CeuG82iW ExhBuMajISiEAE1kOqHf8X4m1AdXjXlO6Jdgj2RxaBN5zKNYzj4SiMQY60GaG/d0 Nxj2EFh4ORnseMIdg/F+yc4j+zoAqBfM+b1uuTQ15zqcOFuBr46c+9dBo1rZzhg3 2g43P5u9DJHIjUQjIGLP =Ng8h -----END PGP SIGNATURE-----

April 4, 2014

Re: [PATCH] ddraw: add dsurface dimension tests, try 7

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for the patch. I'll test it on my Windows boxes as soon as they're done with Linux updates (Gentoo...) and report any failures I find. Am 2014-04-03 17:54, schrieb Patrick Rudolph: + window = CreateWindowA("static", "ddraw_test", WS_OVERLAPPEDWINDOW, + 100, 100, 160, 160, NULL, NULL, NULL, NULL); + + if (!(ddraw = create_ddraw())) + { + skip("Failed to create a ddraw object, skipping test.\n"); + return; + } You no longer need the skip check here. The main functions in ddraw1-ddraw7 check if ddraw creation succeeds and skip all tests if it doesn't + + ret = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); + + ddcaps.dwSize = sizeof(DDCAPS); You're not checking the return value here. I also recommend to rename "ret" to "hr" for consistency with other tests. + ret = IDirectDraw_GetCaps(ddraw, &ddcaps, NULL); + if (ret != DD_OK) + { + skip("IDirectDraw_GetCaps failed with %08x\n", ret); + return; + } Do you have hardware where GetCaps fails? If not, a simple ok(SUCCEEDED(hr), ...) should be enough. +#if _WIN64 || __x86_64__ || __ppc64__ + { + MEMORYSTATUSEX statex; + statex.dwLength = sizeof (statex); + GlobalMemoryStatusEx (&statex); + /* on 64bit surfaces with 2GByte+ are possible */ + if(statex.ullAvailVirtual > 0x80000000LL) + tests[10].ret = DD_OK; + } +#endif Is the #if necessary? Afaics GlobalMemoryStatusEx should work on 32 bit as well. In light of the testbot failures I recommend to check for available physical memory as well. I'm also fine with just dropping the SYSMEM out of memory test until we find an application that depends on this behavior. The parenthesis placement after the function call and if are inconsistent. This applies to a few other ifs as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPmKGAAoJEN0/YqbEcdMwUwEP/A5NCz4xe855Z9jX6iUBWkhw NDhpM/9Wbk5tdekaR3QcrNyCYGCAHnOl/kUsGXeBDwZxCDzRzpfsdpFp0Nux46m+ L/xtf71bhAMYGikeV9r/C+UVBbCslO4KXFcUmx5K43AXcVQGMq+K1yvzhGtKCGZb 6zNCUmhxI2MlNrU9KDp7W7kNhVWMu2ungAjojT5BmaWDgtvS6TWu10jX1rIwQlYF wMOHSIomIBNvPi2vSr8aXLzPhgFCrMg3g8fERUqS3Vk8LJfmJYWJ87hcfPiMGd5A ntDYedg+mhV0ShTk26XCeKMNBfvjcdwWCnHEi1GYmYQ6H/nRDGxkEO/TskiNLuNn IO/rV2TAO9SfzHzHO/VPCGdb6nISGICAP/oA2ryrhINdXtn6eq1kjqQsGUURlqlk Y46P55qgRleYCtqxHjrjhQXDL4anaKj3ApZjGRa9MVC2/SPvIe3UpjlHjN4oeAix ohiOiq7GL/PXXs0zLOKFeVdUoOYpCIuP7MsR/dX9KcJwYQ2U9GT6OEoQPhZT+/B7 Tpv1maEOnn+UCkvcW6BY2eAt3nsznvlKVb73D5t1tLp/LCbKiSqY+8Dk0f75YTyG hEXkawRFLjhXeA6db8ieb2GdftaAnfq1Vxa7wjF4igAccZIhySInrvdnOFhZ4rp+ djHZm23O6ml1uV8Qt0mW =yrSd -----END PGP SIGNATURE-----

April 4, 2014

Re: libwine-print missing when compiling from source

by Alois Schlögl

On 2014-04-03 17:46, Francois Gouget wrote: > On Wed, 2 Apr 2014, Alois Schlögl wrote: > [...] >> Yes, I've followed http://wiki.winehq.org/WineOn64bit. >> >> Unfortunately cups:amd64 and cups:i386 conflict on debian/wheezy. So I >> can install one or the other, but not both. The same holds for >> libcups2-dev (header files). Although libcups2:amd64 and libcups2:i386 >> are both installed. > That's why that page suggests installing libcups2, not cups, and > creating symlinks for the 32-bit version. See: > > http://wiki.winehq.org/WineOn64bit#head-5dd049f4c05d95a80467aa965870ef41b7f… > Thanks for your replies. Yes, I had this in place. Now, its working - I can start Igor Pro. And I can not reproduced the original problem - I do not what the problem was. I'm glad its working. -- Alois

April 4, 2014

Re: [1/5] include: Add dxva2api.idl

by Nikolay Sivov

On 4/4/2014 08:44, Michael Müller wrote: > This first set of patches adds the required interface definitions and > headers which are required for the dxva2 implementation. Please note > that the ugly names of the header files were not my idea, thats exactly > the same name how they're called by MS. Yes, looks like 8.3 rule no longer applies :) > > The last patch of the series implements stub functions for every member > of dxva2.dll, such that applications do not abort anymore when they hit > one of the stub exports. > > --- > include/Makefile.in | 1 + > include/dxva2api.idl | 534 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 535 insertions(+) > create mode 100644 include/dxva2api.idl > +cpp_quote("#if 0") > +typedef DWORD IDirect3DDevice9; > +typedef DWORD IDirect3DSurface9; > + > +typedef DWORD D3DFORMAT; > +typedef DWORD D3DPOOL; > +cpp_quote("#endif") First I thought it's a bit ugly, but apparently that's how it's done in SDK. > +enum > +{ > + DXVA2_PictureParametersBufferType = 0, > + DXVA2_MacroBlockControlBufferType = 1, > + DXVA2_ResidualDifferenceBufferType = 2, > + DXVA2_DeblockingControlBufferType = 3, > + DXVA2_InverseQuantizationMatrixBufferType = 4, > + DXVA2_SliceControlBufferType = 5, > + DXVA2_BitStreamDateBufferType = 6, > + DXVA2_MotionVectorBuffer = 7, > + DXVA2_FilmGrainBuffer = 8 > +}; > + > +enum > +{ > + DXVA2_VideoDecoderRenderTarget = 0, > + DXVA2_VideoProcessorRenderTarget = 1, > + DXVA2_VideoSoftwareRenderTarget = 2 > +}; > + You don't need explicit initializers in this case. > +[ > + object, > + uuid(a0cade0f-06d5-4cf4-a1c7-f3cdd725aa75), > + helpstring("IDirect3DDeviceManager9 Interface"), > + local > +] No need for helpstring(), it's only used definitions participating in typelibs.

April 4, 2014

Re: [PATCH] ddraw: add dsurface dimension tests, try 7

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6141 Your paranoid android. === w8 (32 bit ddraw4) === The test timed out === wvistau64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w2008s64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w7pro64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w8 (32 bit ddraw2) === ddraw2.c:5071: Test failed: Got unexpected refcount 3. ddraw2.c:5090: Test failed: Got unexpected refcount 3. ddraw2.c:5097: Test failed: Got unexpected hr 0. ddraw2.c:5100: Test failed: Got unexpected refcount 3. ddraw2.c:5102: Test failed: Got unexpected refcount 2. ddraw2.c:5108: Test failed: Got unexpected hr 0. ddraw2.c:5111: Test failed: Got unexpected refcount 2. ddraw2.c:5113: Test failed: Got unexpected refcount 1. === wvistau64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w2008s64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w7pro64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w8 (32 bit ddraw1) === ddraw1.c:3968: Test failed: Got unexpected refcount 3. ddraw1.c:3987: Test failed: Got unexpected refcount 3. ddraw1.c:3994: Test failed: Got unexpected hr 0. ddraw1.c:3997: Test failed: Got unexpected refcount 3. ddraw1.c:3999: Test failed: Got unexpected refcount 2. ddraw1.c:4005: Test failed: Got unexpected hr 0. ddraw1.c:4008: Test failed: Got unexpected refcount 2. ddraw1.c:4010: Test failed: Got unexpected refcount 1. === wvistau64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w2008s64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w7pro64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 10 returned 8007000e === w2000pro (32 bit ddraw7) === The test timed out === w8 (32 bit ddraw7) === ddraw7.c:5604: Test failed: Got unexpected refcount 3. ddraw7.c:5623: Test failed: Got unexpected refcount 3. ddraw7.c:5630: Test failed: Got unexpected hr 0. ddraw7.c:5633: Test failed: Got unexpected refcount 3. ddraw7.c:5635: Test failed: Got unexpected refcount 2. ddraw7.c:5641: Test failed: Got unexpected hr 0. ddraw7.c:5644: Test failed: Got unexpected refcount 2. ddraw7.c:5646: Test failed: Got unexpected refcount 1. ddraw7.c:5648: Test failed: Got unexpected refcount 6. ddraw7.c:5765: Test failed: Failed to set cooperative level, hr 0x8876023b. === wvistau64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w2008s64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e === w7pro64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 10 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 10 returned 8007000e

April 3, 2014

Re: [PATCH 5/5] ws2_32: Add an interactive test for interface change notifications.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6142 Your paranoid android. === wxppro (32 bit sock) === sock: unhandled exception c0000005 at 71AB4047 === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

April 3, 2014

Re: [PATCH] ddraw: add dsurface dimension tests, try 6

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6140 Your paranoid android. === w8 (32 bit ddraw4) === No test summary line found Failure running script in VM: network read timed out (wait2:ListSize:0/4) === wvistau64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w2008s64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w7pro64 (64 bit ddraw4) === ddraw4.c:6603: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw4.c:6603: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w8 (32 bit ddraw2) === ddraw2.c:740: Test failed: Got unexpected color 0x00000000. ddraw2.c:3120: Test failed: Got unexpected color 0x000000ff. === wvistau64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w2008s64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w7pro64 (64 bit ddraw2) === ddraw2.c:5744: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw2.c:5744: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w8 (32 bit dsurface) === dsurface.c:310: Test failed: Destination data after blitting is not correct dsurface.c:344: Test failed: Destination data after blitting is not correct dsurface.c:523: Test failed: Surface data after srckey blit does not match dsurface.c:548: Test failed: Surface data after src override key blit does not match dsurface.c:602: Test failed: Surface data after dest key blit does not match dsurface.c:628: Test failed: Surface data after dest key override blit does not match dsurface.c:690: Test failed: Surface data with src key and dest key blit does not match === w8 (32 bit ddraw1) === ddraw1.c:2828: Test failed: Got unexpected color 0x000000ff. ddraw1.c:3968: Test failed: Got unexpected refcount 3. ddraw1.c:3987: Test failed: Got unexpected refcount 3. ddraw1.c:3994: Test failed: Got unexpected hr 0. ddraw1.c:3997: Test failed: Got unexpected refcount 3. ddraw1.c:3999: Test failed: Got unexpected refcount 2. ddraw1.c:4005: Test failed: Got unexpected hr 0. ddraw1.c:4008: Test failed: Got unexpected refcount 2. ddraw1.c:4010: Test failed: Got unexpected refcount 1. === wvistau64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w2008s64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w7pro64 (64 bit ddraw1) === ddraw1.c:4641: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw1.c:4641: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w2000pro (32 bit ddraw7) === Failure running script in VM: timed out waiting for the child process === w8 (32 bit ddraw7) === ddraw7.c:3112: Test failed: Clear with count = 0, rect != NULL has color 0xff0000. ddraw7.c:5604: Test failed: Got unexpected refcount 3. ddraw7.c:5623: Test failed: Got unexpected refcount 3. ddraw7.c:5630: Test failed: Got unexpected hr 0. ddraw7.c:5633: Test failed: Got unexpected refcount 3. ddraw7.c:5635: Test failed: Got unexpected refcount 2. ddraw7.c:5641: Test failed: Got unexpected hr 0. ddraw7.c:5644: Test failed: Got unexpected refcount 2. ddraw7.c:5646: Test failed: Got unexpected refcount 1. ddraw7.c:5648: Test failed: Got unexpected refcount 6. The test timed out === wvistau64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w2008s64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000 === w7pro64 (64 bit ddraw7) === ddraw7.c:6458: Test failed: Pixelformat D3DFMT_A8R8G8B8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_R5G6B5, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 9 returned 8007000e ddraw7.c:6458: Test failed: Pixelformat D3DFMT_P8, test 10 returned 00000000

April 3, 2014

Re: libwine-print missing when compiling from source

by Francois Gouget

On Wed, 2 Apr 2014, Alois Schlögl wrote: [...] > Yes, I've followed http://wiki.winehq.org/WineOn64bit. > > Unfortunately cups:amd64 and cups:i386 conflict on debian/wheezy. So I > can install one or the other, but not both. The same holds for > libcups2-dev (header files). Although libcups2:amd64 and libcups2:i386 > are both installed. That's why that page suggests installing libcups2, not cups, and creating symlinks for the 32-bit version. See: http://wiki.winehq.org/WineOn64bit#head-5dd049f4c05d95a80467aa965870ef41b7f… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

April 3, 2014

Re: [PATCH 3/3] scrrun: Implement FreeSpace() for a drive

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6136 Your paranoid android. === w2000pro (32 bit filesystem) === filesystem.c:1358: Test failed: got 0x00000000 filesystem.c:1482: Test failed: got DEADBEEF filesystem.c:1495: Test failed: got 0x00000000 filesystem.c:1510: Test failed: got 0x00000000 filesystem.c:1518: Test failed: got DEADBEEF filesystem.c:1524: Test failed: got DEADBEEF filesystem.c:1543: Test failed: got 0x00000000 filesystem.c:1564: Test failed: got DEADBEEF filesystem.c:1658: Test failed: got 0x00000000 filesystem.c:1672: Test failed: got DEADBEEF filesystem.c:1691: Test failed: got 0x00000000

April 3, 2014

Re: [PATCH 2/3] scrrun: Implement Read()

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6135 Your paranoid android. === w2000pro (32 bit filesystem) === filesystem.c:1349: Test failed: got 0x00000000 filesystem.c:1473: Test failed: got DEADBEEF filesystem.c:1486: Test failed: got 0x00000000 filesystem.c:1501: Test failed: got 0x00000000 filesystem.c:1509: Test failed: got DEADBEEF filesystem.c:1515: Test failed: got DEADBEEF filesystem.c:1534: Test failed: got 0x00000000 filesystem.c:1555: Test failed: got DEADBEEF filesystem.c:1649: Test failed: got 0x00000000 filesystem.c:1663: Test failed: got DEADBEEF filesystem.c:1682: Test failed: got 0x00000000

April 3, 2014

Re: [PATCH 1/3] scrrun: Implement ReadAll()

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=6134 Your paranoid android. === w2000pro (32 bit filesystem) === filesystem.c:1349: Test failed: got 0x00000000 filesystem.c:1473: Test failed: got DEADBEEF filesystem.c:1486: Test failed: got 0x00000000 filesystem.c:1501: Test failed: got 0x00000000 filesystem.c:1509: Test failed: got DEADBEEF filesystem.c:1515: Test failed: got DEADBEEF filesystem.c:1534: Test failed: got 0x00000000 filesystem.c:1555: Test failed: got DEADBEEF

April 3, 2014

Re: apphelp: add a stub for SdbInitDatabase (try 2)

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > > > + if (path) > > > + FIXME("stub: flags: %08x, path: \"%s\". Unexpected, please > > report!\n", flags, debugstr_w(path)); > > > + else > > > + FIXME("stub: %08x %s\n", flags, debugstr_w(path)); > > > > What's the reason for this if/else? What exactly is not expected and why > > this matters for a stub? > > > > -- > > Dmitry. > > > > It's expected to be NULL in practice, Why do you think that it's expected to be NULL? > I thought it would be helpful for > Focht to easily spot future applications that are using this API. Isn't printing a FIXME enough for that? -- Dmitry.

April 2, 2014